On Wed, 18 Apr 2007, Junio C Hamano wrote: > > But I think that is a separate issue. > > The logic I said I wanted to override in the message you are > responding to is the big toplevel if () else if () ... chain in > process_entry(), and the nested if () else if () ... logic in > merge_file(). They roughly implement what git-merge-one-file > does. Ahh. Ok, in that case, I kind of disagree with you. I think the hardcoded merging rules (ie when two of the SHA1's match etc) are the only sane things to do _regardless_ of any merge strategy. So yeah, we'll always do one level of merging at the pure SHA1 stage, and pick that without actually doing any file-level merging at all. I don't think that's wrong. Maybe it means that people cannot pick some really strange merge that they want on a file-by-file basis, but I think that's simply how "merge-recursive" is defined. IOW, I don't think you should be able to turn git merge -s recursive into git merge -s ours by making attributes say something like *: merge=ours because I think the attributes are really about what we do WHEN we hit file-level conflicts, while the "merge strategy" is a much higher-level thing. They are independent. But maybe there is some real-world and sane usage that shows me wrong. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html