One Big Repo
tchomby at googlemail.com
Mon Mar 2 13:07:00 CET 2009
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.
More information about the vcs-home