Using quilt to store patches

[martin f krafft]

also sprach Stefano Zacchiroli <zack at debian.org> [2009.05.24.1557 +0200]:
> I think the approach hinted by Mehdi is quite interesting and that
> it deserves a bit more of investigation.

Fair enough, I probably don't understand it yet. Let me reply to
your mail first, maybe you can point out where I am misled.

I am also asking Mehdi at the bottom to provide some more details
over the process of making a change to a patch.

> In particular, what do you think you will loose practically using
> that instead of full-fledged TopGit?

From what I understand, Mehdi's (and Guido's) approach require
a branch with one-patch-per-commit, which they rebase. This approach
has two problems for me:

1. due to the rebasing, it's not possible to work with other people,
   unless everyone maintains their own patch queue.

2. each patch on the patch queue branch is presumably the result of
   a squash-commit or the like. The feature has likely been
   developed on a branch of its own, squashed into a single commit,
   and then removed.

   If the patch needs modification later on, you have to recreate
   a branch and work off the single squash-commit. While this
   prevents you from looking at history, the bigger problem is that
   it's repetitive manual work: create branch, cherry-pick patch,
   work, squash-commit delete branch.

   It gets worse if you do publish the feature branch, because then
   you need to keep it up to date with other branches by merging
   before you can work on it and squash-commit.

TopGit automates all of (2) and since it never rebases, it can be
used in a team (1).

> Also, your patch history is trivially versioned as the content of
> debian/patches/ in master.

You will be able to work with diffs of diffs. My head spins when
I have to do that.

Mehdi, I may not be understanding the approach you take when a patch
needs updating. Could you share that with more details with us?

Let's say you have a patch queue with patches A, B, C, and D (D is
the top-most, last patch to be applied) them, and you need to make
a change to B. What exactly do you do?

With TopGit, you'd have four TopGit branches and the patch series
would be created by exporting the patches for each feature branch.
When you need to make a change to B, you checkout B, commit until
you're done, and then let TopGit update branches C and D to ensure
that they apply, before you export the new patch series.

I think TopGit gives you the benefit of working with Git for
everything, and using quilt only to apply the patches. Git offers
cherry-picking, can obsolete patches if the resulting content of two
of them i identical, gives you access to a log, diffs, and much
more. It allows you to develop a feature, rather than versioning
a patch.

We definitely need to make it easier to use though. This applies
mostly to the complexity introduced through the various merges. If
that cannot be simplified, maybe we can find a way to use namespaces
that don't show up in gitk or similar tools?

-- 
 .''`.   martin f. krafft <madduck at d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"violence is the last refuge of the incompetent"
                                                       -- isaac asimov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20090525/ed4af7e2/attachment.pgp>