Sean Whitton writes ("Bug#903132: -fdiverged when `git debrebase
convert-from-gbp` after `dgit push --gbp`"):
> Either they should not require passing it, or dgit-maint-debrebase(7)
> should explain that it will be needed. I'm not yet sure which is right.
I have thought about this and:
In most situations, git-debrebase convert-from-gbp will be able to
make a useful pseudomerge to stitch in the dgit archive view.
The approach is: gdr will find the most recent debian/* tag, make a
set of checks (on archive/debian/* and the changelog), and if so it
can add a pseudomerge to overwrite archive/debian/*.
But: What to do if some of those checks fail ?
Treating them as snags is a little odd because the core of the
convert-from-gbp operation does not depend on making that pseudomerge.
Currently I'm thinking along the following lines:
Each of these checks is a snag. If any of those snags is detected, we
won't create the pseduomerge.
Also, it is a snag if the output from convert-from-gbp going to need
-fdiverged.
So if the checks fail, and this is going to be relevant, the user must
either override the failing check with -fwhatever-it-is, or say not to
make the pseudomerge by specifying -fdiverged.
I'm not entirely sure about this system of interlocking snags, where
the behaviour varies depending on which set of them you chose to
force.
Also what should it do if the user just specifies --force ? I guess
not make the pseudomerge and expect the user to do some suitable
git merge -s ours
later.
The alternative seems to be to expect the user to say one of
convert-from-gbp --no-make-pseudomerge
convert-from-gbp --make-pseudomerge
(at least if --force is specified) or to make some of these things
not be snags.
Opinions welcome. FYI my provisional set of checks is this:
git-describe --always --abbrev=0 --match 'test-dummy/*'
output might be commitid, or tag name
check ff to archive/sametag
check version is parseable
check version is in changelog
then make ff
check divergence as for record_ffq_prev_deferred
Ian.
