There are trouble with file-ids. Most common example is trouble with file which was created in two branches (two repositories) independently, then branches got merged. Most (all?) file-id based rename detection has trouble with repeated merging of those branches, even if there are no true conflicts.
Do you mean if the 2 files should be merged into 1 file? If they should be 2 files with different names there is no problem using file identifiers but if they should be merged into one file then I can see that this would cause problems. You would have to delete one of the files and copy its changes into the other which would create conflicts when that file is modified in the other branch. This is a problem if you *only* have file identifiers.
But if you tracked both file identifiers *and* content identifiers (as I was trying to say in my first post) this wouldn't be a problem would it? When content is changed you use the content identifiers but when files are changed by renaming or deleting you use file identifiers. To me at least it doesn't seem like it's a choice of one or the other or that one is stupid and the other isn't but that you need them both. bzr uses file ids and git uses content ids. It would be nice if there were an RCS that used both - then you get the best of both worlds don't you?
So I don't think you want to use file identifiers to track changes to content (as bzr would do in this case) and you don't want to use content identifiers to track changes to files (as git does, to my understanding, when a file is renamed).
Nick - 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