Re: new stacked git feature

On 13/02/2008, Karl Hasselström [off-list ref] wrote:

On 2008-02-12 16:42:46 +0000, Catalin Marinas wrote:

quoted

The background of this discussion is to have two or more StGIT
repositories and keep them in sync. An idea is to share the exported
patches directory and automatically synchronise them between various
repositories (we already have a 'stg sync' command which I use for
this kind of things but it's not automated).

Yet another idea is to add some metadata to each commit log,
something like a unique id so that one can recreate the stack with
only a GIT revision id, without knowing the base.

I've been trying to come up with a good way to represent undo
information, and my current plan is this:

  * Every time the patch stack is modified (that is, any time an StGit
    command modifies anything at all), a new commit is made to a log
    branch. Each StGit branch has one such log branch.

We already have another commit for the patch history. If we add this,
we end up with 3 commit for each patch command. People already
complained that StGIT is slow, I wouldn't go this route. I even think
we should drop the patch history log and maybe use some git features
like reflog.

For undo, can we not keep the HEAD of the old stacks in a simple text
file? Or maybe use reflogs and only allow as many undos as information
available in reflog.

I wasn't planning to try to build patch stack merging until later, but
here's how I imagine it would work:

  1. All patches are popped, and set to a special "conflicting" state
     with three or more "a" trees: a.ours, a.theirs, a.base0, a.base1,
     a.base2, .... Similarly for the "b" tree and the commit details.
     (Of course, trivial conflicts could be sorted out automatically
     at this point.)

  2. The merged stack base is created with a normal recursive merge.

A recursive merge with the HEAD of another stack containing similar
patches? If yes, when pushing it is likely that the patches already in
the base will be emptied during a three-way merge.

  3. When a conflicting patch is pushed, we do the following:

       1. For each of .ours, .theirs, .base0, ..., create a new "b"
          tree just like we do when we normally push a patch. If there
          are conflicts, autoresolve them like merge-recursive does
          internally.

       2. Create the single new "b" tree by making a recursive merge
          of all these updated "b" trees. Represent any conflicts like
          we usually do when pushing patches.

My idea is to merge each patch with the corresponding commit in the
other branch and leave the base unchanged (like "stg sync"). The
difficulty is in identifying which commit from the other branch has to
be used. We could try guessing by the number of changes or just using
the subject line, assuming that it won't change (or an extra id field
in the commit text).

I find this workflow pretty difficult to implement since the StGIT
patches are pretty volatile. It might be better to use topic branches
instead.

-- 
Catalin