Felipe Sateler writes ("Re: Bug#902534: dgit: needs a better integration story
with patches-unapplied maintainer trees"):
> Gah, I knew there was already a bug about this. And I have even
> participated on it! Sorry for the duplicate.
No problem. I'm dropping 842614 again because we're focusing here in
902534 very much on gbp. That's probably a useful narrowing and thus
a useful distinction between the two bugs.
> But dgit could create such ancestry, couldn't it? If dgit somehow knew the
> package incorporated the pulled changes, it could create the synthetic merge
> commit with the dgit view.
>
> Currently for gbp-maintained packages history looks like this:
>
> U1----U2----U3
> \ \ \
> A1----A2----A3
>
> Where U[N] are the gbp debian/N tags, and A[N] are the dgit archive/[N] tags.
> What I'm thinking is that dgit would do:
>
> U1-----U2---U3
> \ \ \
> A1---A2--F---A3
>
> Where F would be a fake merge synthesized by dgit. I have
> deliberately left out the path from A2 to U2. It might be done via
> gbp import-orig, manual patch application, or whatever. It might be
> even that I forgot to use dgit in the last upload!
How does dgit (or anything else) know that U2 contains all the changes
in A2 ? If it constructs it itself it can know that, but otherwise
someone is going to have to tell it.
> Perhaps this is a possible middle ground: If I could tell dgit "my
> branch includes all changes in A2",
In non-split-brain mode you can do this:
git merge -s ours dgit/dgit/sid
That is you declaring that although your branch is not a descendant of
the archive, it contains all the changes in it (or, at least, all the
ones you want to keep) and that therefore it should be considered fast
forward.
That is, of course, equivalent to passing --overwrite to dgit push.
But you can do it in advance, and if you do, you won't need
--overwrite later.
The difficulty with doing this in split brain mode is that A2 does not
have a corresponding U2 known to dgit. So there is no parent you can
overwrite in advance with git merge -s ours.
If A2 is a dgit dsc import then there is a thing a bit like U2 inside
the dgit dsc import commit structure. But that sort-of-U2 doesn't
have the right ancestry. In the general case it can't do because
dgit's dsc import code cannot rely on U1 even existing, let alone
somehow being able to find it by digging into the git history.
But A2 might even be a fast-forward upload done by a dgit-using NMUer.
In that case there might be nowhere at all any commit whose tree would
correspond to the putative U2. That is likely if the NMUer made a new
patch.
I don't know what exactly happens if you say
git merge -s ours dgit/dgit/sid
if you are on a patches-unapplied branch. I'm pretty sure it will get
rid of the need to use --overwrite on the next push.
One option might be to provide a "preemptive overwrite" command to
dgit, which would do an appropriate git merge. In non split brain
modes
dgit overwrite 2
would be the same as some suitable git merge -s ours, but it would
do the same kind of checks as dgit push --overwrite=2. Then the
next dgit push wouldn't need --overwrite.
In split brain mode it would probably make a pseudomerge overwriting
the patches-unapplied dgit dsc import, if it can find one. I have no
idea what it would do if there was no such dsc import. Maybe it could
invent a root commit with a special note in it, which dgit push would
later recognise ?
But maybe the actual answer is just "you tell dgit this by putting it
in your changelog".
> perhaps dgit could generate the
> history above and then --overwrite would not be needed? Similar to
> the --force-with-lease option to `git push`, it would allow
> overriding, but only if the remote matches what we expect.
dgit push --overwrite already works like --force-with-lease. By
default it will only overwrite an archive version which is mentioned
in your d/changelog. So if someone else uploads, you aren't racing
with them: your dgit push --overwrite will spot the problem and bail.
I think this is explained under --overwrite in dgit(1).
--overwrite is still necessary because it is not possible for dgit to
tell whether the branch are on, which has a stanza for "2" in the
changelog, is actually based on the final version of "2" as it was
uploaded.
This is because a stanza for "2" might easily exist in a branch which
was about to be released - except that a last-minute bug was
discovered, and fixed. If your branch is derived from that earlier
unreleased version, it would look (if you just looked at the
changelog) to be an update which contained everything in "2". But if
you uploaded it you would undo the last-minute bugfix.
I think maybe the fact that I am writing this all here suggests we
need better wording in the --overwrite section of dgit(1).
> At least, dgit does not make this problem any harder. Having to pass
> --overwrite may *seem* like "making it harder" but what is really
> going on is that the Debian archive has no fast forward checks,
> so the old dput/dupload workflow is like passing --overwrite
> *on every upload*.
>
> Right, but if you add a check that needs to be overriden "often",
> the check is more an annoyance than a help. Even more so when the
> override flag is a very broad "stomp whatever is on the server".
It's only needed for NMUs. Are they that common ?
> People who want a delta queue workflow which is better integrated with
> git should perhaps consider using git-debrebase instead of gbp :-).
>
> Most changes to debian packages are not patches, so a workflow that
> inflicts the rebase pain for every release would not be preferred
> for me.
I'm not sure I follow.
With git-debrebase you do not need to actually rebase unless you
actually want to edit the patch queue, or incorporate a new upstream
version. If you like you can just commit commit commit into debian/
and not rebase until you want to do one of those things. You can even
add upstream patches onto the end of your queue, without rebasing.
Also, I'm not sure what you mean by "rebase pain". Maybe you expect
more pain than git-debrebase would inflict ?
> Perl is definitely not my strong suit, but I hope at least this
> discussion will end up providing a clearer view for someone with
> better perl-fu and the needed motivation.
Right. I'm very happy to participate on that basis :-).
Thanks for your input.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
