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 <kha@xxxxxxxxxxx> 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.
> 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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
