Nicholas Allen wrote:

quoted text
>> The reason this is a good example is simply the fact that it should 
>> totally silence anybody who still thinks that tracking file identities is 
>> a good thing. It explains well why tracking file identities is just 
>> _stupid_.
>
> I'm unfamiliar with git so I could be totally wrong here!
> 
> I know that bzr supports file renames/moves very effectively and I 

This means: _usually_ works, doesn't it? Emphasisis on "usually"?

quoted text
> understood that git doesn't support this to the same extent (correct me 
> if I am wrong as I have not used git at all!).

Git supports renames/moves in different way. Instead of recording renames
(which has trouble on it's own, for example rename via applying patch)
in the repository it _detect_ renames when needed.
 
quoted text
> If that is the case, could that be because bzr gives each file its own 
> id and can detect this easily but git's content based approach can't? If 
> so then claiming file identifiers is *stupid* seems a bit extreme. So I 
> would have thought *both* file identifiers and line/content identifiers 
> are needed for tracking changes made to the files and to their contents 
> respectively. When a file is copied then the contents are copied and it 
> is given a new file identifier. When a file is moved it keeps the same 
> identifier. So don't you need file identifiers as well as line/content 
> identifiers?

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.

Read Linus post about file-id based rename detection:
  Message-ID: <Pine.LNX.4.64.0610201049250.3962@g5.osdl.org>
  http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/18458

Not that contents based rename detection doesn have it's own pitfals:
  Message-ID: <7virha4cnm.fsf@assigned-by-dhcp.cox.net>
  http://permalink.gmane.org/gmane.comp.version-control.git/31899
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


-
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