Colin Watson writes ("Bug#928473: dgit: not clear what to do when earlier
uploads used dgit but intermediate ones didn't"):
> --overwrite looks sort of right, but it gives the example of having
> incorporated NMU changes which isn't my situation, nor is it true that
> this is the first time the package has been pushed using "dgit push" to
> the suite in question. And it tells me that it's going to make a
> pseudo-merge, which doesn't seem like what I want because the version in
> the archive already has an exact representation in my branch: I have a
> dgit/dgit/sid ref here whose tree is identical to my 1.5.71 tag,
> although the history is synthetic.
--overwrite is intended for this situation. The documentation talking
about "NMU changes" is speaking loosely, and should mention "changes
in uploads which weren't done with git" too.
It will make a pseudomerge of the synthetic import. Is that a problem
for you ? The effect of that is that:
- The published git history actually contains a representation of
1.5.71.
- Someone who looks at your history can see that you did
make it ff from 1.5.71.
- If we are lucky, someone who did "dgit clone" when 1.5.71 was in
sid, will not get a locally made pseudomerge because your history
already has the pseudomerge. This can avoid having needlessly
divergent client-side histories.
- If someone has done dgit clone since 1.5.71, and pushed the result
to a public git server, your upload will be ff from it.
(In the future we may have a robot which automatically imports all
uploads to the dgit suite branches, in which case making the
pseudomerge will be essential to avoid rewinding the suite branch.)
> --deliberately-not-fast-forward seems only dubiously appropriate,
> because I'm not rewinding history. The version in the archive is
> 1.5.71, which is a direct ancestor of what I'm trying to upload and has
> an exact representation in my branch's history. HEAD of
> https://browse.dgit.debian.org/debconf.git/ is also a direct ancestor of
> what I'm trying to upload. Does it actually mean that my branch isn't
> fast-forwarding from the synthetic representation of 1.5.71 that dgit
> constructed, because 1.5.71 wasn't uploaded using dgit?
--deliberately-not-fast-forward is a force option which requests
*either* of these kinds of not-ff. That is, the not-ff it requests
encompasses both "not ff from synthetic local dgit import" and "not ff
from the dgit server history". It doesn't distinguish (and, on the
client, can't reliably distinguish) purely-local synthetic commits,
from public ones.
In fact --deliberately-not-fast-forward is not honoured by the Debian
dgit server except for NEW packages. The server will still not let
you rewind the dgit suite branch; that requires admin intervention.
(And of course right now the server can't see the synthetic import.)
In this situation --deliberately-not-fast-forward would work to let
you do the upload without a pseudomerge, but if anyone else is
tracking the same package with dgit it would generally needlessly
different histories and have the other unfortunate properties I
mention above.
> Ideally I'd like dgit to notice that the history of my branch in fact
> has everything it needs (as in, there's a commit there that has a tree
> identical to what's currently in the archive) even though the uploads
> between 1.5.53 and now weren't made using dgit. But maybe I
> misunderstand something? Is it OK for me to use
> --deliberately-not-fast-forward in this situation, which seems ideal
> from my point of view? If so it would perhaps be helpful for the
> documentation to say a bit more about this situation, because it seems
> that it must be somewhat common for some maintainers of a package to use
> dgit and some not, and this is exactly the kind of situation that arises
> from that.
I think the documentation should encourage you to use --overwrite.
Indeed I would encourage you to do that.
You are free to use --deliberately-not-fast-forward if you want to,
although I think it is less desirable.
HTH.
If this makes some kind of sense I think we should treat this as a
docs bug.
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.
