Re: [Gnu-arch-users] graphical merges

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > Well, if I was trying to write my own merge, I wouldn't base it
    > on star-merge.

    > All I'd really need is a way to list candidates for ANCESTOR, so
    > my tool can select one and the user can override.  The rest can
    > be implemented in terms of get (--link) or library-find.

Yikes.

star-merge is already "expert" at one best way to pick ANCESTOR and
already expert at finding or building-in-tmpdir the ANCESTOR tree.
star-merge is already expert at invoking mkpatch in such a way that,
instead of the usual patching, "something else" (diff3 currently)
happens (but, meanwhile, mkpatch still does all the tree-rearrangement
stuff in the usual way).

There might be _other_ best ways to pick ANCESTOR -- but star-merge
should learn about any new ones we come up with.

I'm just about certain that the right way to build new 3way merges is
to tweak star-merge in minor ways.


    > It's not that I'm opposed to updating star-merge, I just think
    > it would be easier this way.

I doubt it would be easier and, more to the point, any new
functionality you write that wouldn't simply duplicate what star-merge
already does should _also_ be available in star-merge.


    >> (The next thing we want, both for 3-way and 2-way merges, is a
    >> clean-up of what it takes to be able to commit-with-conflicts so that
    >> multiple people can work on resolving conflicts, using revision
    >> control to coordinate their efforts.)

    > It seems to me that a branch is the correct way to handle conflicts. 
    > foo--conflicts--base-0 is a tag of the previous revision.  patch-1 has 
    > the changes, including conflicts.  patch-2 to patch-N are created as 
    > people resolve the conflicts.  Then you merge the conflict branch into 
    > the original.  That should separate the merge-applying from the 
    > merge-fixing, which are distinct.

    > I'm a little fuzzy on how this should work for users, though.

That may be a good policy for using the feature that's needed but the
feature that's needed is just a clean way to cope with
committing-with-conflicts.   There's a need to make sure that all
conflict information is preserved.   There's a need to make sure that
if you merge _into_ a tree that already has conflicts, that the old
conflicts are preserved in a sane way.   There's a need to be able to
quickly query a tree to find all remaining conflicts.

Really what I'm talking about is just some formatting tweaks to how
conflicts are recorded and/or some tweaks to =tagging-method.

-t