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.