On 2008-07-12 10:58:44 +0100, Catalin Marinas wrote:
> 2008/7/8 Karl Hasselström <kha@xxxxxxxxxxx>:
>
> > On 2008-07-07 21:54:01 +0100, Catalin Marinas wrote:
> >
> > > Anyway, have you heard of anyone else using sync apart from me?
> >
> > No, I haven't.
> >
> > I've tried to understand what it does, and as far as I can tell it
> > doesn't do quite what I want. (What I want is the ability to 3-way
> > merge StGit patch stacks, so that I can modify the same patch
> > stack in several places and merge back and forth. From what I
> > recall, the sync command is more like a 2-way merge -- that is, it
> > doesn't take the last common ancestor into account. But it's been
> > a while since I studied it.)
>
> No, the sync command is a 3-way merge between the top of a remote
> patch, the top of the current patch (current HEAD actually) and the
> bottom of the remote patch as ancestor. It also has a mode to
> synchronise with a patch file and it applies the patch onto the
> bottom of the current patch and does the merging between patch tops
> afterwards.
>
> This is not ideal as I have to deal with safe conflicts several time
> (maybe adding git-rerere support would help). If you have better
> ideas for keeping two stacks in sync, I'm happy to accept them (or
> maybe just a different workflow).
Yeah, the actual _tree merging_ is 3-way, but the _patch merging_ is
2-way, since you don't consider the patches' latest common ancestor.
So you run into problems much like what you'd get if you tried to
apply a patch, change it, then apply it again, etc.
When merging two branches with stack logs, you can find the stack log
of the merge base, and use that to 3-way merge the patches.
( To 3-way merge a patch:
1. You have the common ancestor (A), and the two diverged patches
(B and C).
2. Push A, B, and C separately onto the same commit. (If there are
conflicts at this stage, one probably wants to just ignore them
automatically, like merge-recursive does.) Now, A_b == B_b ==
C_b. (_b is the patch's bottom; _t is its top.)
3. 3-way merge A_t, B_t and C_t to get the new patch top.
4. Commit message etc. can be merged with a standard 3-way merge.
To merge an entire patch stack, first merge the stack bases (with an
ordinary 3-way merge, for example), then merge any changes is the
patch order, and then merge all the patches one by one.
As I've said before, I haven't actually tried this, so I don't know
if it'll work as intended. But it sounds right ... and it works out
OK for trivial cases like when the patch is only modified in one
branch, or when no patch bottoms are changed by step (2). )
--
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
