From: Junio C Hamano Date: Mon, 24 Oct 2005 00:58:07 GMT Subject: Re: LCA2006 Git/Cogito tutorial Message-ID: <7vu0f7u3xc.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <4358597A.6000306@catalyst.net.nz> "Martin Langhoff (CatalystIT)" writes: >>>(ii) You say: >>> >>> - Very fast stupid merge >>> ... and very smart, slow merges when stupid won't do > > Almost. No, truly, I'm very impressed with git-merge.sh, which first > does the simple git-read-tree -m, and it can then try several merger > scripts to resolve the index. The "smartest" merge resolver we have > follows renames, but we could have language-specific and > project-specific resolvers, for instance. I should not be saying this because I am the primary guilty party, but you should not be so impressed. Being able to specify which merge strategy to use is a useful thing, but I do not think being able to try more than one merge strategies automatically, while it has some coolness value, is very useful in practice. The language-specific or project-specific part should be made orthogonal to merge strategy modules, which currently is not. The primary thing Daniel's git-merge-resolve and Fredrik's git-merge-recursive do is to figure out which paths can be resolved without merging the file contents, and which paths need to be resolved with file contents merge, and they use different strategies to find which 3 variants of the contents to use for that final merge. But at the end of the day, merging the contents is done by running 'merge' in either case. This should be made either customizable, or we ship our standard one that can be extended to first run 'file' to see the file content type of what is being merged and run content specific merge program if there is one. Even if we did that, we are still doing 3-way merge; git-merge framework may not mesh very well when we want to use something like codeville merge which is not based on 3-way.