GitLab

This is something of a re-imagining of !15, with a number of alterations.

First, it's proposed that we start revision-tracking the list of submodule symbolic tags by storing it as a file within each superproject. Since !15 was written, we've merged CI_Source!29 (merged) which lists submodule tags (including any post-checkout alterations due to updating to CrossCompilationSupport branches) in a file called Manifest. It would therefore be neat to adopt this name, and its slightly different formatting, so once the CrossCompilationSupport fudge has been removed, anyone looking at Manifest will automatically see the revision-tracked version. So where prodversions output to stdout and prodcommit -f took a filespec, prodadd is hard-coded to use filename Manifest and uses the same format as the CI job does.

prodadd is a bit more symmetrical in operation than prodversions and prodcommit -f were, in the sense that prodversions would read from the index, but prodcommit -f would read from the working tree. prodadd takes on the functionality of both, and reads from the working tree by default, whichever direction it operates in. proadadd can also be made to read from the index, using the command-line option --cached (or -c for short).

The tool naming is now more consistent with other git commands. The original prodcommit only acted to create a commit from the contents of the index; in that respect it was a close analogue of git commit. By contrast, the functions of git add and git submodule add are to update the index from the working tree; prodadd is therefore a separate tool and named to reflect the fact that its function is also primarily to update the index (of the superproject).

Another way in which prodadd is more consistent with other git commands is that git clone, and other commands that for normal tracked files would update the superproject's working tree, such as git checkout, will by default only update the revisions of submodules in the index, and not in the working tree. prodadd follows this pattern. This represents a significant speed saving (by a factor of 5 to 10x) if you don't need the working tree copies of submodules to be updated. This is particularly noticeable on Windows where this operation can last several minutes. If you do want the working tree submodules to be updated, you can pass --update-submodules or -u to prodadd, or alternatively at any later time you can still use git submodule update.

One last improvement over prodcommit -f is that prodadd --manifest is also capable of adding and removing submodules (although it has to guess some properties of added submodules, so for maximum flexibility, some use of git submodule add may occasionally still be required).