Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)
On Wed, Sep 18, 2013 at 05:42:17PM +0100, Ian Jackson wrote:
> Adam Borowski writes
> > Here's one way:
> > rm -rf .pc debian/patches
> > echo single-debian-patch >>debian/source/options
> > The rm needs to be repeated, either in the "clean" target or perhaps by
> > dgit.
> I don't think removing .pc and debian/patches will DTRT because
> dpkg-source -x will produce a directory containing them. dgit's idea
> of "the source tree from the source package" is "whatever dpkg-source
> -x produces".
> I think even if you put single-debian-patch in debian/source/options,
> you'll find that dgit still needs to make the spurious commit on your
> git head to represent the results of dpkg-source --commit (that is, to
> represent the changes to .pc and debian/patches.
If you consider .pc and debian/patches to be droppings, removing them
will produce a sane format close to what you want. In fact, this can
already be represented in git: just put the droppings into .gitignore.
This might need a "git clean -dfX", but that already matches the
"everything in git" principle.
> It would be nice if there were a source format that:
> * Could represent every change to a source tree (including the
> deletion of upstream files!)
> * Did not insist in including droppings in the trees it manages.
I don't understand the arguments against 3.0 (git). For every 3.0 (quilt)
package, you can produce a 3.0 (git) with exactly the same data (but not
It is claimed that it can smuggle some not visible data. That's what
prune is for. Git goes a long way towards saving old data for recovery
purposes, but deleting object not reachable from HEAD you ship is no
As for the need to review past commits: quilt is no different. You must
(at least in theory) check the tree's state before and after applying
every single patch. Why would the same thing in git be worse?
> * Supported multiple tarballs.
This would require merge commits, but it otherwise doable.
> > This turns "3.0 (quilt)" into "3.0 (sane)" and allows using version
> > control without having to go out of your way to work around quilt.
> Single-patch "3.0 (quilt)" is still IMO insane. The droppings in .pc
> and debian/patches (which require workarounds in dgit) also mean (for
> example) that a debdiff of a one-line change contains a giant pile of
Not if you have that poo in .gitignore.
. Metadata that differs:
quilt:upstream quilt:changed git
mtimes yes no no
empty directories yes no no
sockets/devices yes no no
symlinks yes no yes
refs to trimmed parents no no yes