On Wed, Jun 27, 2018 at 10:01 AM Ian Jackson <
[email protected]> wrote:
> Control: forcemerge -1 842614
>
Gah, I knew there was already a bug about this. And I have even
participated on it! Sorry for the duplicate.
> Felipe Sateler writes ("Bug#902534: dgit: needs a better integration story
> with patches-unapplied maintainer trees"):
> > Currently, dgit-maint-gbp(7) says:
> > > dgit pull can't yet incorporate NMUs into patches-unapplied gbp
> branches.
> > > You can just apply the NMU diff the traditional way. The next upload
> will
> > > require --overwrite.
> >
> > This is an unfortunate limitation, given gbp is pretty popular (although
> > not universal)[1]. It would be great if dgit could better integrate with
> > such workflows. In particular, there are two different steps:
> >
> > 1. Not require --overwrite after incorporating an NMU.
> > 2. Provide some tooling for pulling NMUs into the maintainer tree.
> >
> > I think the first one is more important. The second one is already
> > partially solved by gbp itself (via gbp-import-dsc).
>
> I don't think these can be separated. dgit wants the git history
> structure to imply that what is in the maintainer's HEAD contains
> everything that is in the NMU. That's analogous to the usual git fast
> forward check. --overwrite is always needed when something has been
> done which does not turn source-code-containment into
> git-branch-ancestry.
>
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!
Perhaps this is a possible middle ground: If I could tell dgit "my branch
includes all changes in A2", 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.
> 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".
> I think doing this right is probably possible but it requires a lot of
> thinking and will be distinctly nontrivial. I don't intend to spend
> time on this in the near future. If I do work on making `dgit pull'
> work in more cases, it will probably be to make git-debrebase cope
> with general merges, as discussed in git-debrebase(5).
>
> 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.
> Of course contributions to improve this area would be very welcome. I
> am happy to review patches etc.
>
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.
--
Saludos,
Felipe Sateler
