|
Boost : |
From: Henrik Sundberg (storangen_at_[hidden])
Date: 2007-06-08 14:49:49
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:
http://git.or.cz/gitwiki/GitFaq#head-f7dc61b87eab4db58fe90ce48cc1d47fd50e6bea
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.
/$
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk