> There are trouble with file-ids. Most common example is trouble with file
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html