[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] graphical merges

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] graphical merges
Date: Sat, 03 Apr 2004 16:02:35 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4

Tom Lord wrote:


       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.

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.

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]