Re: new stacked git feature

On 2008-02-22 13:54:12 +0000, Catalin Marinas wrote:

"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).

This shouldn't be a problem with a per-branch log -- it would have the
state of both ancestors before the merge, and the merged state
afterwards, so nothing should be lost.

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

quoted

  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.

No. First a 3-way merge (A (base), A, X) with result X, and then a
3-way merge (A (base), B1, C1) with a result that has to be computed
by the merge algorithm. Just as if you were pushing both versions of
the patch separately.

The basic algorithm is:

  1. You want to merge patches A->B and C->D. Their closest common
     ancestors are X0->Y0, X1->Y1, ...

  2. Select the base tree K you want to push the patch on. This is
     either another patch, or the bottom of the stack.

  3. For each of A->B, C->D, X0->Y0, X1->Y1, ..., push them separately
     onto K (in parallel, not on top of each other). If there are
     conflicts, just commit the conflict markers. The patches are now
     K->B', K->D', K->Y0', K->Y1', ...

  4. Merge B' and D' with Y0', Y1', ... as bases. In case of
     conflicts, ask the user to resolve them.

Obviously, K may be the same as one or more of A, C, X0, X1, ..., so
that some or all of the pushes are trivial.

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.

I never really liked that approach; it kind of treats patches as
trees, when they are in fact the diff between two trees. It only works
because the boundary between two applied patches is a tree. But the
user thinks she's manipulating patches and not patch boundaries, which
is why the history looks strange.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle