[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
metadata[1]) bits.

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
rocket science.

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
> poo.

Not if you have that poo in .gitignore.

[1]. 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


Reply to: