Re: [Gnu-arch-users] Fast commits

[Tom Lord]

       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.

I guess I'd describe this as "medium-hanging fruit" and it's up for
grabs --- anyone who wants to beat me to it should post a UI design
sketch first and be prepared for some tweaks.   It's relatively
trivial -- just more than a 10-line patch.

One commonly suggested mistake to not make: don't propose replacing
the invocation of `patch' with invocation of an interactive tool.
Things shouldn't be intermingled that way.  We want two phases: figure
out the set of ANCESTOR/HIS/MINE files in phase 1; let the user wander
over those with a merge tool in phase 2.

(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.)

-t