[ANNOUNCE] Example Cogito Addon - cogito-bundle

[Jakub Narebski]

Linus Torvalds wrote:
> 
> On Fri, 20 Oct 2006, Aaron Bentley wrote:
>> 
>> All solutions have disadvantages.  We prefer the disadvantages that come
>> from using file-ids over the disadvantages that come from using
>> content-based rename detection.

If I remember correctly, git decided on contents (plus filename)
similarity based renames detection because 1), it is more generic
as it covers (or can cover) contents moving not only wholesome rename
of a file, and 2) because file-id based renames handling works only
if you explicitely use SCM command to rename file, which is not the
case of non-SCM-aware channel like for example patches (and accepting
ordinary patches is important for Linux kernel, the project git was
created for).

Another problem with file-id based rename handling is not handling
file copying (correct me if I'm wrong), and troubles with removing
or renaming a file, then having new file with old name.
 
> That's fine, but please don't call the git rename handling "maybe" or 
> "partial", like a lot of people seem to do. 
> 
> Git _definitely_ handles renames, both in everyday life and when merging. 
> Some people may not like how it's done, but other (I'll say "equally 
> informed", even though obviously I know better ;) people really don't like 
> the way bzr or others do their rename handling.

I think that "partial" refers to not complete handling of renames
for file history; pathspec doesn't follow history. Although the
information is there in SCM, it's the tools that need extension
(the --follow of rename following single file pathspec limit
proposal).

There was also suggestion of rr2-cache, which would record corrections
to automatic rename detection (rename/copy conflict resolving) 
if I remember correctly.
-- 
Jakub Narebski
Poland