I’ve been using Git for a while now and love the features and flexibility in workflow it allows. The ability to commit early and often is a huge deal for me and really fits into my way of working.
One feature of Git I’ve heard mentioned many times but have yet to get my head around is the fact that it tracks content rather than file history which supposed makes dealing with renaming and moving files much better.
Can someone explain why this is? I haven’t noticed anything special in this regard compared to SVN. What am I missing?
Git stores three pieces of data separately:
A consequence of this is that if you have the same data in several files, git only has to store it once, because the structure (which contains directories and files) only has to point at one content object.
Similarly, if a file does not change from version to version, git only has to store that file once. Multiple history objects point to the same content.
Some of the user visible benefits is that git blame is very good at seeing code move across files especially if you tell it to look real hard with
git blame -C. It’s also some of why git is so compact and fast, the structure is very simple, very cheap to walk and doesn’t repeat itself.One of the downsides is that git doesn’t store file copies and renames, it just guesses, and sometimes it’s wrong.
This blog entry provides a decently well digested but still detailed discussion of what content tracking buys git. If you want to know more, you can watch Linus’ Google Tech Talk on Git or read the transcript.