Re: [Gnu-arch-users] Re: Future of GNU Arch, bazaar and bazaar-ng ... ?

[Martin Langhoff]

On 8/23/05, Magnus Therning <address@hidden> wrote:
> It is however a quite common use case, especially among Linux kernel
> developers:

yes, but it's done in StGIT, not GIT (before I'd have said: it's done
in quilt, not BK). StGIT is a patch-manager that is very adept at
that. It makes no pretense of keeping track of a project history. It
keeps track of a stack of patches that are very malleable -- you can
edit _the patch_ without recommitting. I think it keeps some history
of your edits of the patch even, but I may be wrong about that.

The assumption is that the 'floating' and very flexible "patch layer"
is subjects to edits and reedits, and this does _not_ entere the
formal history of the project until the patch is ready. Once the patch
is vetted and ready for merging, it is merged, and all that history of
a thousand bad-commits and reedits is lost.

You can say that it is either very valuable history being discarded,
or that it is just noise, and that in a large project with many people
involved you want to merge a patch that is readable, clear and
concise. And that the thousand missteps and edits aren't much use, and
are just noise.

It is not a bad division of roles: there's git doing the hardcore scm
and coordinating things around the patches that have setttled into
formalized commits, and stgit allowing people to trade, track and
reedit patches in more flexible ways. As stgit doesn't even try to
provide a real, long term history, it is free to be much more
flexible. The stuff in it, however, is "work-in-progress".

Needless to say, I'm warming up to the model. ymmv ;)

cheers,


martin