On Fri, 08 Jun 2007 20:49:49 +0200, Henrik Sundberg wrote:
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: [...]
Yes, but this is substantially different from being able to *track* fragments being moved. Of course, if we are talking about *large* fragments, then, yes, it works. If we are talking about a single 10 line function being moved between two 1000 line long files, then, no, it does not track it in any real sense. I would classify "deals correctly with fragments of code moving across files" as being automatically able to apply a change made in one branch to that 10 line function after it has been moved to another file in a different branch. I'm pretty sure that no state-based analysis of files could do that... (which is all that GIT does, can do, or wants to do). What GIT will allow you to do is do a search for fragments of files, and identify where they appear... it's not quite the same thing. pihl -- Change name before @ on From: to phil for direct email.