Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying
--quilt=single"):
> I'm reluctant to introduce something else like this when we already have
> the git-debpush tags thing. Hmm -- is there some reason why dgit
> couldn't put information in those tags in the same way?
Well, I'm a bit confused right now, but: I think a potential problem
is that if the branch format is converted without making a tag, things
can go wrong. I'm not sure precisely how we avoided this with
git-debpush; part of the answer might be that git-debpush always works
in split brain mode.
> Right, but the pile of Emacs addons I maintain using dgit-maint-merge(7)
> will never hit any of those behaviours. So it's a high cost to impose
> on someone in a position such as mine.
Hmmm. I am very reluctant to recommend a practice which will induce
other tools to corrupt data. Note that the corruption might be
experienced by downstreams (ie, people outside Debian) who are trying
to use dgit to manipulate packages from Debian.
Whereas inventing a dropping in debian/source/ seems straightforward
and precisely correct. It's a description of the maintenance/update
practice that generated the tree you're working with, and (by
implication) how updates to it should be made.
Is there anything stopping us inventing an "unofficial"
debian/source/options entry ?
... tested it ...
It causes these messages:
dpkg-source: info: using options from dgit/debian/source/options: --wombat
dpkg-source: warning: --wombat is not a valid option for
Dpkg::Source::Package::V1
which is probably too annoying.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> 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.
