On Wed, Dec 19, 2007 at 11:16:12AM -0800, SJS wrote:

As far as the common ancestor.  The reason that I said it is important is
that if you don't chose a good common ancestor, you may end up giving your
file merge tool way too much work.

Does this include file-renames?

Yes.

And yes, selecting the correct ancestor is important. CVS tracks
ancestors, but in a limited way -- when you do an "update" and you've modified a file locally that's been changed in the repository,
the ancestor is right there, and obvious.

Likewise, when you merge in a branch, the ancestor is always obvious;
it's the version that was tagged with a branch tag.

Well, it's obvious if you've only merged the branch once.  Let's say I have
a long-lived branch and I want to bring in the mainline changes
periodically.  Each time, I basically get to resolve the same conflicts
again, since it doesn't have any way of tracking the individual merges.

It also breaks down if you merge back and forth between two branches.

The problem with common ancestors with CVS comes when you merge two
branches multiple times, or merge from branch A to branch B and then
back to branch A.  The second and subsequent merges use the wrong
ancestor, leaving it up to the developer to have the discipline to
tag branches before merging.

Boy, I think I need to read your messages in reverse, since I just wrote
about the same thing :-)

But it leads into the justification for:

Git also has another interesting tool, that I haven't used yet, that they
call 'rerere - Reuse recorded resolution of conflicted merges'.  It is for
when you have long lived topic branches.  Instead of having to remember the
same conflict resolution and resolve it the same way, once you resolve
something, it can remember how you did it.  It basically allows you to keep
your tree clean, but not make you resolve the same conflicts over again.

It's fairly pick about when it will do this, but apparently it often saves
quite a bit of work.

I can see how.  It would be a fairly rare occurrance for most users, but it
would save a TON of work.

It comes in handy with a long branch that you want to occasionally do
"practice" merges on.

Dave


--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to