John A Meinel <[EMAIL PROTECTED]> wrote: > Martin Langhoff wrote: >> 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. > > Then again, this is also handled well by having a mainline and a > micro-branch, and doing a final rollup commit into the mainline. > In fact, that is exactly what StGIT is doing, only they throw away the > microbranch when they are done.
A micro-branch is equivalent to an StGIT patch but StGIT allows multiple patches, each patch based on the previously applied ones (they are not parallel, you would use separate branches for this). StGIT allows easy reordering of the patches - you just pop everything from the stack and push them in the order you want, StGIT commuting the patches via the three-way algorithm (which might not be exact and have some problems but it is faster than the Darcs commuting algorithms). The way I used GNU Arch in the past was to have separate branches for the bigger developments I was doing, like linux--mainline--2.6, linux--arm--2.6, linux--arm-platform-X--2.6 etc, with a strict order of pulling changes (from the former to the latter). This had the drawback of using a lot of space and not being very flexible, like re-basing arm-platform-X directly on the mainline. Another big issue was that the Linux kernel people do not like to receive big patches and I always had to split the arm-platform-X diff manually before submitting it. Splitting a patch, even if using emacs to help with splitting hunks, still takes a lot of time and you might need to do it over and over again if the patch is rejected or someone merged new stuff which affects your diff. With StGIT, you just create small patches for the logical changes you need. For examples: common-cpu-support-for-platform-X, interrupt-controller-X, base-platform-X, device-A, device-B etc. These patches are ordered and you know for sure that they apply cleanly to the base of the stack (which usually is the same as the mainline kernel). Doing a pull command for the latest mainline kernel moves the base of the stack to the new remote HEAD and re-generates all the patches so that they apply cleanly. This operation saves you plenty of time spent for preparing a patch. One could also make the repository available for pulling and the patches are seen as GIT commit objects. At the end of http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial you can find a bit of the theory behind this (quite simple though). > I think having another branch minimizes the total number of concepts, > rather than adding *yet-another* thing to be learned. It's not yet-another thing since StGIT is not original. The idea started with Quilt and many people like it. StGIT follows the same philosophy but with the advantage of full integration with GIT and better merging (three-way) than simply using the 'patch' tool. -- Catalin _______________________________________________ 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/
