From: Phil Richards (news_at_[hidden])
Date: 2007-06-10 11:50:06
On Fri, 08 Jun 2007 20:49:49 +0200, Henrik Sundberg wrote:
> 2007/6/7, David Abrahams <dave_at_[hidden]>:
>> on Thu Jun 07 2007, "Henrik Sundberg" <storangen-AT-gmail.com> wrote:
>> > 2007/6/7, Phil Richards <news_at_[hidden]>:
>> >> 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.
-- Change name before @ on From: to phil for direct email.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk