Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying
--quilt=single"):
> In particular, we now think that dgit should honour git-debpush's quilt
> modes stored in Git tags: that's #1111423.
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).
> We haven't discussed making dgit start honouring its *own* quilt modes
> embedded in upload tags. If we were to do that, then with regard to
> *this* bug, there would no longer be a regression for our flagship
> dgit-maint-merge(7) workflow, in that you wouldn't have to do any local
> git configuration and wouldn't ever have to pass quilt mode options.
I don't think there is any meaningful distinction here: dgit makes
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.
> We would still have lost 'dpkg-source --commit' with single-debian-patch
> but I think we are both okay with that.
Yes.
> Taking a step back, it would overall be simpler if dgit and git-debpush
> worked the same way with regard to quilt modes embedded in tags: they
> both defer to the latest one written by either of them unless overridden
> on the command line.
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.)
> So how about we extend #1111423 to making dgit read quilt modes out of
> both its own tags and git-debpush's tags, and consider that to resolve
> the regression I'm concerned about in this bug?
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 <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
