Aaron:
I've been giving some thought to merge lately. Thinking about
how to satisfy Linus, who wants a graphical three-way merge.
So far, I've come up with this:
- star-merge is not a fundamental operation, in the sense that
get, update and commit are. It's not an archive operation, in
the sense that it does not produce or store revisions.
- Since it's not an archive operation, the implementation
doesn't matter to anyone but the user. A good merge operation
will produce fewer conflicts. A bad merge operation will
produce more. But no one else will be affected.
- To satisfy Linus, itla would need to break star-merge into
several steps:
You're missing state, man.
I'm absolutely in favor of modifying _tla_, not putting off for itla,
to make star-merge suitable for use with a graphical merge tool.
Basically, star-merge should have an option with a few minor
variations for just dropping the raw data (ANCESTOR and HIS) into a
dir (or pointing at their occurence in a revlib) and then it's easy to
write tools that combine star-merge and any of the many existing
graphical merge tools.
(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.)