* tchomby <[email protected]> [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/> _______________________________________________ vcs-home mailing list [email protected] http://lists.madduck.net/listinfo/vcs-home
