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

[Catalin Marinas]

John A Meinel <address@hidden> 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