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

[Catalin Marinas]

address@hidden wrote:
>> GIT doesn't natively do cherry-picking. It tries too hard to merge
>> branches fully to be good at that. But you can use Stacked GIT (StGIT)
>> which does cherry picking and many patch tricks on top of GIT. As git
>> is doing the 'formal' SCM, StGIT stacks patches on top of a formally
>> committed history. Patches in the stack are extremely malleable - a
>> weirdly nice concept of being able to "edit the patch". One of git's
>> GUIs, qgit, is poised to start doing cherrypicking, possibly based on
>> StGIT.
>
> Definitely cool. How many patches can it track before it starts falling
> apart?

It is quite slow with big number of patches, especially if you use it
over NFS, but the same big problem exists in Arch. I'm profiling it
and already reduced the timings to a half compared to the latest
release. Most of the time is spent in the git merge/checkout tools,
the time actually spent in StGIT is tens of milliseconds.

The idea of StGIT is to keep a set of patches (tens usually) always on
top of the main repository you are tracking until they get merged into
it. At that point, the StGIT patch would become empty and can be
safely removed. StGIT is not intended to be used as an SCM where you
can create thousands of patches. You expect the patches to be merged
upstream and removed from the stack. It closely follows the Quilt
philosophy.

Another nice thing is that you can modify a patch if it is not
acceptable upstream. It even detects if a patch merged upstream was
modified by the gatekeeper and you can modify and re-submit what's
left unmerged from that patch.

What made StGIT possible is the possibility of modifying the DAG
structure in a GIT repository. The DAG structure is based on the
commit objects and in GIT you can create a commit with any number of
any parents you want, though the plain GIT scripts or Cogito usually
use the current commit object as a parent of a new commit.

-- 
Catalin