I've been trying this out on my primary use case of
prodadd -s
)prodadd -m
)for which it works great. I then spotted in this comment block that it should be possible to add and remove entire components too, but got some errors there:
When I tried removing DragAnObj from the Disc products as a test it errors with
error: the following file has changes staged in the index:
RiscOS/Sources/Desktop/DragAnObj
(use --cached to keep the file, or -f to force removal)
fatal: Submodule work tree 'RiscOS/Sources/Desktop/DragAnObj' contains local modifications; use '-f' to discard them
error: the following file has changes staged in the index:
RiscOS/Sources/Desktop/DragAnObj
(use --cached to keep the file, or -f to force removal)
I think this is because I'd previously been picking on it as a test case for regressing by tag then removing it. If I try removing one I hadn't been fiddling with it works OK.
I tried adding the -f
switch as prompted but that's caught out by the arg check right at the beginning, then I concluded the error message wasn't from this script directly (the mention of --cached
threw me) and was probably from one of the git commands it issues.
Perhaps having the -f baked into the command would be worthwhile? I want to remove it so just blow it away.
And for an added component it mostly worked, adding MakeModes gives
remote: Compressing objects: 100% (31/31), done.
remote: Total 266 (delta 19), reused 50 (delta 19), pack-reused 216
Receiving objects: 100% (266/266), 198.59 KiB | 493.00 KiB/s, done.
Resolving deltas: 100% (127/127), done.
fatal: ambiguous argument '^{commit}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
fatal: malformed index info 160000 ^{commit} 0 RiscOS/Sources/Apps/MakeModes
I think that's because I didn't specify a tag. Maybe I expected it to give the HEAD
of the trunk and update the Manifest for me? There's no error if I do give a tag, so it's probably just user error.
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 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).
ROOL (904dc30a) at 11 Feb 10:55
[diffrelease] Strip false-positive markers from commit logs
CI_Source!27 and CI_Source!28 introduce a method of supressing false positive CI test results by using a magic marker in commit logs. However, we proably don't want these to be reflected in release notes. Adapt diffrelease to remove any such lines it finds.
CI_Source!27 and CI_Source!28 introduce a method of supressing false positive CI test results by using a magic marker in commit logs. However, we proably don't want these to be reflected in release notes. Adapt diffrelease to remove any such lines it finds.
Would it perhaps have been better to compare against $(git config init.defaultBranch)
rather than just adding another hard-coded magic branch name?
ROOL (29f9ef45) at 06 Feb 22:39
[srccommit] Detect 'main' as being a default branch like 'master'
Since Git and GitLab now default to using 'main' rather than 'master' as the default branch for new repositories, treat both names in the same way when deciding whether to increment the major version number.
Since Git and GitLab now default to using 'main' rather than 'master' as the default branch for new repositories, treat both names in the same way when deciding whether to increment the major version number.
Python 2 is obsolete, so make compatible with Python 3.
git-mtime.py has a few small changes and remains compatible with Python 2, however BBCBasicToText.py is no longer Python 2 compatible.
BBCBasicToText.py still doesn't do character set translation, though it can now be easily added.
Python 2 is obsolete, so make compatible with Python 3.
git-mtime.py has a few small changes and remains compatible with Python 2, however BBCBasicToText.py is no longer Python 2 compatible.
BBCBasicToText.py still doesn't do character set translation, though it can now be easily added.