Josh Triplett <j...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
