[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] graphical merges
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] graphical merges |
Date: |
Sun, 4 Apr 2004 07:03:41 -0700 (PDT) |
> 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
- Re: [Gnu-arch-users] Fast commits, (continued)
- Re: [Gnu-arch-users] Fast commits, Tom Lord, 2004/04/03
- Re: [Gnu-arch-users] graphical merges, Aaron Bentley, 2004/04/03
- Re: [Gnu-arch-users] graphical merges, Matthieu Moy, 2004/04/03
- Re: [Gnu-arch-users] graphical merges, Aaron Bentley, 2004/04/03
- [Gnu-arch-users] A general way to get a specific revision, Stefan Monnier, 2004/04/03
- Re: [Gnu-arch-users] A general way to get a specific revision, Aaron Bentley, 2004/04/03
- Re: [Gnu-arch-users] graphical merges,
Tom Lord <=
- Re: [Gnu-arch-users] graphical merges, Aaron Bentley, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Tom Lord, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Aaron Bentley, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Tom Lord, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Juliusz Chroboczek, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Matthew Dempsky, 2004/04/05
- [Gnu-arch-users] Smart merging [was: graphical merges], Juliusz Chroboczek, 2004/04/05
- Re: [Gnu-arch-users] Fast commits, Robin Farine, 2004/04/03
- [Gnu-arch-users] Re: Fast commits, Stefan Monnier, 2004/04/03
- Re: [Gnu-arch-users] Re: Fast commits, Miles Bader, 2004/04/03