Russ Allbery writes ("Re: : Re: Bug#863578: Initial upload to experimental
should probably still merge history"):
> When uploading a package with dgit to unstable for the first time, the
> recommendation is to use --overwrite, which will add a pseudo-merge of the
> existing history to the newly-pushed commit representing that upload, this
> correctly showing in the Git history that the newly-uploaded package is a
> descendent of all those previous packages uploaded to unstable.
Ah.
> Using --new does successfully upload to experimental, but my assumption
> was that this new dgit branch then has no pseudo-merge with the unstable
> history and therefore looks like a disconnected branch relative to the
> history of the package in unstable. This seemed like a minor flaw worth
> mentioning, although it's pretty minor and doesn't interfere with using
> dgit going forward.
Well, dgit only _requires_ that each individual suite branch is fast
forwarding. So it is not part of the data model that experimental
must be descended from a contemporaneous sid.
Ie, some who does this
dgit clone pkg
cd pkg
git checkout dgit/dgit/sid # (actually, would be already)
dgit pull experimental
is not guaranteed to find that it's a fast forward update, or indeed
even that git can make a reasonable merge attempt.
OTOH trying to arrange that this does work well is sensible, and AIUI
was your laudable aim.
--overwrite is not the tool for this. It's there to help you conform
to that data model but is not a general tool for making pseudomerges.
You could have simply done this:
# on branch destined for experimental
dgit fetch sid
git merge -s ours dgit/dgit/sid
dgit push-source
The result would have been that the hypothetical user, above, would
find that `dgit pull experimental' was ff by virtue of your
pseudomerge. That's what git merge -s ours does: declares something
to be a fast forward update without regard to the actual contents of
the thing being overwritten; it should be used when you know by some
other means that the actual code history is consistent with the
pseudomerge you are making, even if the git revision graph does not
currently represent it. (You can also use a pseudomerge to trash
unwanted changes, of course.)
I'm not sure that all of this is worth specific documentation, and IMO
it's certainly not worth specific implementation effort, but I'm
always open to suggestions for how to improve the docs.
There's a separate bug report about --new --overwrite not working,
which I will fix. The --overwrite ought to be a no-op in that case.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> 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.
