Package: dgit
Version: 8.4
Severity: wishlist
Sam Hartman pointed out the following possible workflow practices:
1. Use `3.0 (quilt)' with single-debian-patch
2. Expect dgit to generate or update debian/patches/
3. Not keep debian/patches in git at all
4. Have a salsa branch which does not contain dgit dsc import(s)
I have not analysed exactly what combinations of these are reasonable
but at least some combinations are. Point 4 requires a split brain
mode: the dgit branch needs the pseudomerges. Likewise point 3.
I think there is a coherent possible operation mode for dgit which:
* Does all the usual quilt fixup for the quilt mode, during push
* Does *not* put the results on the user's own branch
Ie, we want split brain mode. NB that this does *not* depend on the
package being `3.0 (quilt)'! So it should not be --quilt=. Rather,
it is semi-orthogonal. --quilt={gbp,dpm,unapplied} all imply split
brain, but split brain should be possible without them.
I think all of --quilt={linear,auto,smash,nofix,nocheck} are
potentially coherent in split brain mode.
Outstanding questions:
* What should this thing be called in the documentation ?
Currently we say "split view quilt mode" (see eg the docs
for --save-dgit-view) but making it available more widely
makes that wrong and it will also make it more visible.
* Does the existing machinery for quilt fixup implicitly assume
non-split-brain, or is the implementation as simple as setting the
split brain flag ?
* Which of the following do we want:
(i) --split-view={yes,auto,no} where
dgit --split-view=no --quilt=dpm
is an error
(ii) --[no-]force-split-view with no way to force
no split view
* I guess split view should be controllable from a config
option.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
