From: Martin Langhoff Date: Sat, 19 Feb 2011 15:22:29 GMT Subject: Re: Merging limitations after directory renames -- interesting test repo Message-ID: In-Reply-To: <20110219101936.GB20577@sigill.intra.peff.net> On Sat, Feb 19, 2011 at 5:19 AM, Jeff King wrote: > So here's a patch series. It's built on your other 3 patches (all of > which I thought looked good, btw). Right, this is looking better! Applied Linus and Jeff's patches, and things are much more civilized. Now, I still have a ton of cases where the 2 branches renamed it just slightly different. In those cases, what I want to do is have a merge helper script that does... git merge-helper --prefer-path foo/orig/README foo/preferred/README foo/other/README if git could keep the rename trios that it recognizes during the merge operation in a "merge notes" file, we could just name git merge-helper --prefer-path foo/preferred/README and have it infer the "non-preferred" paths. The result of the operation should be the same as if git had magically known what I wanted to do during merge: git attempts a git-smart diff3 type merge, and stores the results accordingly in the index. Even for a large messy merge like this, it means I can say git merge git merge-helper --prefer-path src/templates/themes/default/* other/dir/foo/* and that will clear out 99% of the stupid work with minimal fuss; leaving the interesting merge work to be cleared up by hand. I suspect that teaching git merge to accept about 'preferred paths', and perhaps "cache/learn" about them, is also desirable. Harder though. Thoughts? cheers, m --  martin.langhoff@gmail.com  martin@laptop.org -- Software Architect - OLPC  - ask interesting questions  - don't get distracted with shiny stuff  - working code first  - http://wiki.laptop.org/go/User:Martinlanghoff