Re: new stacked git feature

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 21/02/2008, Karl Hasselström <kha@treskal.com> 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