Re: new stacked git feature

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

On 2008-02-20 23:06:07 +0000, Catalin Marinas wrote:
 > There is also a situation when patches on the remote stack were
 > reordered and with some conflicts fixed. In this case, merging gets
 > even more complicated (I think darcs solves this by making all the
 > patches immutable but the base feature of StGIT is that patches are
 > easily modifiable).


The scheme I described should be able to handle this. When a patch is
 pushed, its base is set, and we can just make a normal 3-way merge.

 Consider a stack with two patches, a:A->B and b:B->C (A, B, and C are
 commits). In one branch, this is modified to a:A->B1 and b:B1->C1; and
 in the other, the patch order is changed so we get b:A->X and a:X->C.

 When we merge these, the base is unchanged (so still A), and the patch
 order is b, a (since it was changed in one branch but not the other).

"stg sync" does pretty much the same now but in a more manual way. I
don't really like the way the conflicts are presented - i.e. you don't
know which patch was modified afterwards because the patches lose this
information (they are not topic branches).

  1. First we push b. The A->X variant applies trivially, but the
     B1->C1 variant needs the standard 3-way merge.

3-way merge with X and B1 as base? This leads to the current "sync"
issue, you can't tell which patch was original and which was modified.

Just a thought (not that I'd like this feature in StGIT). Someone
tried a project some time ago, similar to StGIT, but using topic
branches rather than individual commits per patch. The GIT history
looked very ugly, especially after re-ordering, but the advantage was
that you can avoid rebasing patches and simply merging changes from
bottom patches into top ones. This would make synchronisation of
patches between branches much easier.

-- 
Catalin