One Big Repo

[tchomby]

On Mon, Mar 02, 2009 at 10:17:52AM +0100, Aristotle Pagaltzis wrote:
> 
> The point is that in git, if you change a single file somewhere
> in a subdirectory, then all of the tree objects from the root
> down up to the one containing that file object will change.
> (Unchanged subtrees, in contrast, will be shared by commits.)
> 
> Now, when you ask for the history of a file, git has to work
> through *all* of the commits and narrow down the list to those
> commits in which that file changed. That’s what they mean when
> they say that git tracks entire trees only, not files.
> 
> If you have a huge repository, and you only make single unrelated
> changes, then looking at the history of a single file will be
> rather inefficient, because there will be lots of commits to
> examine in which that file remains unchanged.
> 
> That is why it’s considered a good idea to break things down
> along units of stuff that gets changed together rather than
> throwing tons of unrelated crap into a single repository.

Hmm. Okay, understood, but I wonder just how big a repository would have to get 
before this started to be a problem? Git seems pretty fast. And like I said 
before if your repo really did get that big you could always archive it and 
start again. So I'm tempted to ignore this potential problem.