Using quilt to store patches

Mon May 25 18:29:01 UTC 2009

also sprach Stéphane Glondu <steph at glondu.net> [2009.05.25.1438 +0200]:
> You sound like you are developing "complex" features in your Debian
> packages, features that might be concurrently developped inside a
> packaging team. This doesn't sound right for me. I never do such complex
> development inside a package. Most of the time, patches are just fixes
> to make the upstream package more Debian-friendly, or patches taken from
> upstream's VCS. But maybe I don't maintain "real-life" packages...

I radiated the wrong impression. I think, branches are good and
useful for the simplest cases. If all you need to do is change a bit
of Makefile[0], then why should it still live on a branch, the place
where you turn to if you ever need to make another related
change[1]?

0. e.g. http://git.debian.org/?p=collab-maint/topgit.git;a=commitdiff;h=728be702d0a1e2a0edf8e7dd7ce937c881c9a000
1. http://git.debian.org/?p=collab-maint/topgit.git;a=commitdiff;h=71006efac06e50531c1df1a29aec1c7ddb371895

I don't deny that the log/graph of such a branch, when managed with
TopGit, gets messy to the point where it's almost useless to the
human consumer[2], but that's a different problem, isn't it?

2. http://git.debian.org/?p=collab-maint/topgit.git;a=shortlog;h=refs/heads/debian/locations

I see your argument and I agree that I don't actually "develop"
inside the Debian packaging checkout. I use TopGit mainly in
upstream-like scenarios and I love it. I'd simply like to find
a unified approach for both types of tasks.

> >    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.
> 
> This "manual" work is trivially scriptable. The same way as
> TopGit's work could be done "manually" ;-)

My point is that TopGit actually does that manual work already.

> >From my point of view, the problem with TopGit is that I don't
> (need/have to) use it often enough to be familiar with it. On the other
> hand, I am much more familiar with plain git and I don't have to think
> long when using it, so I am at ease with Guido's approach.

Yes, even thought I think the TopGit UI is quite alright, the
innards and what it does to the history are way to confusing. TopGit
exposes too much of its internals, and this is a problem.

> > 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?
> 
> # you are on you re-created patch-queue branch
> git rebase -i A
> # mark B for editing and save

I've never used git-rebase --interactive in this context, but it
makes great sense. Thanks for the explanation.

> I think our role as Debian (or whatever) packagers is versioning
> patches, rather than developing features :-)

Interesting argument. I'll have to sleep on that. ;)

> > 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?
> 
> Sure. But as I said above, the gain seems too anecdotical most of
> the time (in the context of packaging for a distribution) to
> bother learning a new tool.

I agree, except that I also wonder if there isn't a way in which we
could make the genericity of the TopGit approach easier accessible
to everyone.

Thanks for some good arguments. I'll need to try this approach
Mehdi presented, unless any of you feel like providing a short
run-down with examples. I don't think I can quite visualise it yet,
especially not in a team context.

-- 
 .''`.   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

"and no one sings me lullabies,
 and no one makes me close my eyes,
 and so i throw the windows wide,
 and call to you across the sky"
                                                   -- pink floyd, 1971
-------------- 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/5c8dce75/attachment.pgp>