> On Sun, Jul 17, 2011 at 6:03 PM, Andy Singleton <a...@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/
