Re: Feedback on 3.0 source format problems

[Russ Allbery <rra@debian.org>]

Josh Triplett <josh@joshtriplett.org> writes:

> That page already captures my primary issue with "3.0 (quilt)": it acts
> like a version control system, and interacts poorly with other version
> control systems.

I think it's better to think of it as a portable interchange format for
version control systems than a version control system itself, although I
admit that's a fine distinction.

The huge advantage that I see with 3.0 (quilt) is that it offers (although
doesn't require) the ability to represent the *separate, individual*
changes you have made to upstream sources as separate commits that could
be rendered as such in any version control system of your choice.  You can
just not do that and produce a single patch, of course, but if you take
the time to do so, you have something that can easily be moved from one
version control system to another without losing the most significant
information (the separation of changes into conceptual changesets).

Furthermore, it forces a rebased, clean representation of the patches,
which I for one hugely prefer to the mess that you get if someone was
packaging in Git and just randomly commits things directly to the
packaging branch intermixed with merges from upstream.  A few releases
done that way will leave you almost completely unable to extract a rebased
patch set against the current upstream source.  (I have made this mistake
so many times with my own packages.)

I certainly don't want to work with quilt directly when maintaining the
package, since as you say it's a bad version control system.  But with
tools to import and export the patches into a rebased version control
branch (which is basically what gbp pq does), it works pretty well.

I think the forced rebasing is huge, and is a significant feature for me.
But then, I'm a rebase-not-merge person in the perennial Git flamewar.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>