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 - 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