2007/6/7, David Abrahams <dave@boost-consulting.com>:
on Thu Jun 07 2007, "Henrik Sundberg" <storangen-AT-gmail.com> wrote:
2007/6/7, Phil Richards <news@derived-software.ltd.uk>:
On Thu, 07 Jun 2007 10:21:10 -0400, David Abrahams wrote:
Yeah; I get the impression that GIT even deals correctly with fragments of code moving across files.
I believe that that impression is incorrect. Because GIT tracks file state only (no explicit rename or copy tracking), it use a similarity comparison between states to try and identify when a rename actually occurred so it can track the "history" of content. If a fragment is moved, the similarity check will not identify that fragment. The two files will end up being viewed as completely independent by all parts of GIT including the merge algorithms.
I got the same impression as David. This was highlighted as something special to GIT. /$
It would be good to get a definitive answer about that.
The GitFaq for "Why does git not track renames?" says: http://git.or.cz/gitwiki/GitFaq#head-f7dc61b87eab4db58fe90ce48cc1d47fd50e6be... On a second note, tracking renames is really just a special case of tracking how content moves in the tree. In some cases, you may instead be interested in querying when a function was added or moved to a different file. By only relying on the ability to recreate this information when needed, Git aims to provide a more flexible way to track how your tree is changing. /$