On 8/23/05, Magnus Therning <[EMAIL PROTECTED]> 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 _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
