On Wed, 18 Apr 2007, Junio C Hamano wrote: > > Yes, but in the case I had trouble with, I know what I want to > see happen when we DO hit file-level conflict on RelNotes > symlink. The ancestor says Documentation/RelNotes-1.5.0.txt, > the maint branch says Documentation/RelNotes-1.5.0.1.txt, while > the current branch says Documentation/RelNotes-1.5.1.txt. The > logic in merge_file() simply says "we would punt on file-level > conflicts for symlinks" without giving a chance for low-level > drivers to interfere. Ahh, ok. So it really is a file-level conflict, it's just that our traditional merger didn't handle them at all, so we said "nobody can do it". Fair enough. That does sound like a misfeature, although I would also claim that expecting merge strategies to handle symlinks is likely to fail horribly. So maybe each strategy could have "sub-strategies" for other file types. Ie something like [merge "ours"] name = pick our own version driver = /bin/true symlinks = /bin/true ie we'd use tyhe "driver" name for regular files, and the "symlinks" name for symlinks and if no "symlinks" entry exists, we error it out as a conflict? 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