dgit should do git-debpush's quilt mode autodetection.  git-debpush
already reads quilt mode outs of tags made by dgit; it should happen the
other way round, too.

This is important for when tag2upload users turn to dgit to, e.g., do an
NMU in accordance with dgit-nmu-simple(7), or upload binaries, or just
use its wrappers of sbuild and pbuilder.  It would be jarring to find
they now need to pass quilt modes all the time.

Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single"):

CCing that other bug.  This message is mostly about
   dgit: should do git-debpush-style quilt mode autodetection
(which FTR I agree with, but I think is nontrivial).
DEP-14 tags which contain the quilt mode information, which look
for these purposes exactly like tag2upload tags.

But, there is a complication.  dgit needs to support NMUs, uploads to
distro A taking history from distro B, etc.  A dgit-based NMU
(dgit-nmu-simple(7)) uses git history which may have maintainer tag
containing dgit metadata.  It might also have dgit-generated dsc
imports.  More generally, work done from the dgit view (from
dgit-repos, or from an archive/ tag) needs to *not* use the
maintainer's quilt mode.  It must default to --linear.

A maintainer who uses --quilt=single might git merge from the dgit
view.  If an NMUer used --quilt=linear, they would then have the
NMUer's DEP-14 and archive/ tags in their history pointing to the
previous upload, but we wouldn't want to switch their quilt mode.

I forget the details of the precise algorithm in git-debpush, but if I
remember rightly it is partly driven by in-tree information (eg the
changelog) and maybe some knowledge of Debian version number
conventions.  I think that's fine for git-debpush.

For dgit I think we need to think about this in a much more serious
way.  Ie, we should understand what the data model is, and try to
develop an algorithm which we can prove will DTRT.  (Or at least,
won't do anything too bad.)

I don't think we should try to guess whether something is using an NMU
git workflow by looking at Maintainer information, or version number
conventions.  That information is political, and doesn't necessarily
tell you what git workflow is in use.  We need to determine the git
workflow by looking at the git history.

I'm not even sure that my scenario of a --quilt=single maintainer
merging a --quilt=linear NMU is distinguishable, in the data, from a
co-maintainer decision to change quilt mode.

Yes.

If we can come up with a sound way for dgit to determine the quilt
mode automatically, then I think we should adopt the same algorithm in
git-debpush.

(Or to put it another way: any algorithm that is correct enough for
dgit's much wider range of use cases, is also corredct for
git-debpush.  But not vice versa.)

I think this is a fine plan for resolving #1031793, but having read
what I write above you may think it will be too difficult.

Ian.

Ian Jackson writes ("Bug#1111423: Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single"):
...

Also, I think there would be nothing wrong with a non-default option
in dgit to have it use git-debpush's algorithm.  --quilt=maintainer
or something.

Ian.

Ian Jackson [04/Mar  6:31pm GMT] wrote:

All good points, I agree with the importance of the issues you raise
here.

Not sure quite what you mean -- too difficult such that we should look
for an alternative solution to #1031793?