Re: new stacked git feature

From: Karl Hasselström <kha@treskal.com>
Date: Feb 22, 2008, 15:19 UTC
Message-ID: <20080222151914.GB19172@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0802220554x4c0a6c98q39e8b253bb108f1e@mail.gmail.com>

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.

Show 8 quoted lines

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

Show 7 quoted lines

> 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