begin quoting David Brown as of Wed, Dec 19, 2007 at 10:55:41AM -0800: > On Wed, Dec 19, 2007 at 10:42:39AM -0800, SJS wrote: > > >And hey, I was reading the webpage. It suprised the hell out of me that > >if I _don't_ have a three-way merge program installed, configured, and > >accessible, I'm toast. I haven't taken any time to experiment with the > >merging in hg or git. > > It is a little annoying that it seems to just fail if the tool isn't > installed.
Like I said, I haven't tested. If it just aborts, that's annoying. If I get a file with <<<<<<<<<<<<<common-ancestor-spec blah blah blah =============local-version-spec blah bleah =============incoming-version-spec bleah blah >>>>>>>>>>>>> then it's only a problem with documentation. :) (Although, version numbers would help. I'm finding I like treating the version numbers as opaque strings far more than actual opaque strings. I can't remember an opaque string.) > With git, it basically stops, and lets you run a merge tool at that point. > You can even use different tools for different merge cases, since some > might do better than others. That's actually a pretty good idea. > 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? 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. But CVS isn't distributed, so keeping track of common ancestors with implicit information works fine -- and doesn't transition well to the distributed model used by git and hg and friends. 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. In effect, leaving it up to the developer to track and declare the common ancestor. Manually. Errors abound. Hilarity ensues. 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. -- Procedures requiring discipline don't work well with random developers. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
