> On Sun, Jul 17, 2011 at 6:03 PM, Andy Singleton <andy_at_assembla.com> wrote:
> > TREE CHANGE
> >
> > We can identify tree changes by pattern matching. This is the same tactic
> > that git uses, without any other tree change tracking.
[Paul Burba]
> Could you provide a bit more explanation of what you mean here? For
> those of us not familiar with the inner workings of git.
I'm not terribly familiar with git internals, but I think what he's
getting at is that git does not track tree changes, but instead,
_deduces_ tree changes from changesets. If, within a single commit,
one file disappears and another file appears with similar content, git
interprets, after the fact, as a move.
There are several ramifications. One, I'm not sure how well this works
if the delete and the add are in separate commits - i.e., a file is
resurrected from history. Maybe that is tracked in some other way.
Two, git attempts to reconstruct _content_ moves, not just tree moves.
That is, if a significant chunk of a file (say, a function) disappears
and reappears in another file, this is tracked as well, even if it's
not the whole file. So, a file rename is really just a special case of
content moving between files.
Note that the complexity of this approach (deducing content moves after
the fact, rather than tracking tree changes) scales by the size of the
commit, not the size of the tree. So the assumption is that even in
large trees, any given commit is relatively limited in scope.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2011-07-18 22:16:32 CEST