Status of dgit (good for NMUs and fast-forwarding Debian branches)
My original announcement was quite cautious. I've also recently seen
an article in LWN which was also rather cautious. I think it's
probably a good idea to set out what the current state of play is:
dgit's current functionality seems to be in reasonably good shape, but
it lacks additional features which are important in some workflows.
dgit currently supports the following situations very well for DDs:
* You're are not the maintainer, and want to cherry pick a patch from
upstream, apply a patch from the BTS, or whatever. Ie, NMUs and
private changes.
In this situation you do not need to know anything about the source
code management practices of the maintainer (unless the package is
still using some kind of hideous old debian/rules-based patch
system). I recommend liberal use of git-clean and git-reset.
* The package has an existing fast-forwarding git branch whose
content is exactly the same as (or can easily be made the same as)
the Debian source packages.
The following situations are not currently supported well:
* Your signing and login keys are on a host which is distant from the
build and test host. Ie, debsign -r and debrsign. If you have
enough bandwidth you can work around this by copying the git tree
and build outputs to your signing host and running dgit push there.
I am working on improving this; it's a SMOP but not trivial.
* You are not a DD. Fixing this is sadly blocked on changes in
Debian's infrastructure including ftp-master and alioth. I have
started those conversations but it looks like nothing is going to
happen quickly.
I don't think this limitation is acceptable so if it persists I
will perpetrate some kind of guerrilla workarounds. But I don't
expect improvement on this front for at least a month or two.
* You are the maintainer and want to have a quilty kind of workflow.
If you are the maintainer and are currently using a git-based patch
stack system, dgit fetch will at least convert NMUs (whether made
with dgit or not) into git commit(s) for you to incorporate into
your patch stack (git-cherry-pick etc.), and you can then use your
existing workflow for build and upload.
But dgit push won't work for you because your tip git commit
probably isn't a fast forward from the last upload. Supporting
this workflow well in dgit push involves some significant design
work. I have been thinking about this but it's not trivial.
I should also mention a non-goal:
* I have no plans to support a workflow where dgit's git tree
contains different contents to the source packages.
My view is that the source code is the source code. If something
is not needed for [d]git users then it is not needed in the Debian
soure package either; conversely if you need to put something in
the Debian source package then by definition it is source code and
should be in your vcs too.
Furthermore, because dgit's need to bidirectionally gateway between
git and the archive, it is difficult for dgit to do this properly.
For example, if there are files in the source package that weren't
in the last git commit pushed with dgit, then the git trees
synthesised by dgit from source package (which dgit fetch/clone
makes when the last upload was not done with dgit) would contain
those files. So the files would seem to have been created by the
non-dgit-using upload.
dgit's goal is that you should be able to use dgit's git tree in
all situations where you could have used the source package
directly. If there are things in the source package which aren't
in the dgit git tree then that's not the case.
It may be that this means that there need to be separate git
branches for dgit and for the sparser source.
Thanks,
Ian.
Reply to: