One Big Repo

[Aristotle Pagaltzis]

* tchomby <tchomby at googlemail.com> [2009-02-27 11:35]:
> It's generally said that when using git it's best to break
> things up into many small repos, e.g. one per project, module,
> etc., rather than dumping it all into one big repo, and the
> same advice has been given about using git for your homedir. I
> can see why this is a good idea for source code, but for
> something like versioning your homedir I don't see it.

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.

I’m not sure yet where I stand on the one repo vs many repos
question when it comes to homedirs.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>