Why I Chose Git
Aristotle Pagaltzis (via Mark Pilgrim):
And between the two, git has the better repository format—it’s much more robust (designed to make changes inherently atomic) and despite all this, is simpler than the repo format of any other VCS. It’s also efficient—an entire repository with all of the project history will often take less space than a Subversion checkout. (But git needs periodic, manually-initiated vacuuming, say every couple of weeks or so, else it will grow as you work; Mercurial’s repo format is slightly more efficient and it doesn’t have that issue. But it’s not inherently robust, and observing a repository while changes are under way will reveal inconsistent data.)
3 Comments RSS · Twitter
A parallel I observed when using git on the MacPorts project for 2007 and only running git-gc once the first time is a pattern that reminds me of disk fragmentation. In fragmentation you often observe instances of it that are not worth the time it takes to defrag because there will be no real measurable space savings nor speed improvement per the length of time it takes to run the defrag.
In other words running git-gc to save a few megs and IMHO see negligable speed difference at best tends to make m say MEH when people use having to run git-gc as a con.
I don't really hear anyone who actually uses git complain about it anymore then I hear users complain about how fragmented their HFS+ volumes are
Yeah, I tend to git-gc once at the beginning and then git-repack/git-prune every month or so. I don’t think it’s necessary to keep gc’ing everything into a single packfile.
