I think the happy medium between one big repository and too many small ones is to have one default repository for your homedir and a few (but not too many) additional repositories for things that don't belong in the default repository for some specific reason.
One big advantage of having most stuff in a single default repo is moving it around. If I decide to rearrange some of the top level dirs in my homedir, even delete some dirs or add some new ones, or move some files from one top-level dir to another, I can do this with git mv etc, and the changes will be versioned. If each top-level dir was its own repo it would be very awkward to do this sort of thing, you're sort of tying yourself in to your top-level organisational decisions. I change my mind a lot, so I hate that. Example additional repos would be for passwords and the like (although this idea of committing an encrypted tarball into the default repo sounds nice), for large or binary files, etc. My rule is that there has to be some specific, good reason for adding a new repo. For example, I didn't like my hpodder (podcast downloader) database file because it was a binary file that was getting large, and I don't want my default repo getting too big. So I moved hpodder's config dir into its own repo and I no longer worry about it. This fake bare repositories approach seems needlessly complicated to me, and not being able to use gitignore files would drive me crazy, I use gitignore a lot. I keep all of my git repositories in a ~/git directory: ~/ git/ default/ hpodder/ private/ . . . I use my dotfilemanager script (https://github.com/seanh/dotfilemanager) to maintain symlinks in my homedir to the files in the git repositories. This is quite flexible. One thing I have started using recently is git submodules. Take my dotfilemanager script, it's a publicly-available project that has its own git repository, but I also want a copy of dotfilemanager to exist in my ~/scripts directory, which is on my $PATH, and is versioned in my 'default' git repo. I don't want to maintain two copies of the script, one in the public dotfilemanager repo and one in my default repo, that would be awkward. So I added the dotfilemanager repo to my default repo as a submodule, located at ~/git/default/scripts/_dotfilemanager/, then I added a symlink to the default repo: scripts/dotfilemanager -> scripts/_dotfilemanager/dotfilemanager.py. The end result is that there is only one copy of dotfilemanager, it is versioned seperately in its own repo, but there is still a dotfilemanager script in my scripts dir and on my path. I now do this with a number of scripts that I wrote for my own personal use and want to have in my scripts dir, but that I also want to host in a public git repo somewhere. http://vimcasts.org/episodes/synchronizing-plugins-with-git-submodules-and-pathogen/ http://book.git-scm.com/5_submodules.html On Thu, Mar 03, 2011 at 09:53:27AM +0100, Dieter Plaetinck wrote: > anyone? > > > Begin forwarded message: > > Date: Tue, 22 Feb 2011 21:49:24 +0100 > From: Dieter Plaetinck <die...@plaetinck.be> > To: firstname.lastname@example.org <email@example.com> > Subject: fake git repositories.. how far do you go? > > > for those using "fake git repositories", > > From: > http://she.geek.nz/archives/546-migrating-my-homedirectory-from-one-repo-to-many.html > http://firstname.lastname@example.org/msg00078.html > I could not really understand why one would actually _want_ multiple fake git > repositories. > it seems to me that the more of them you have, the more cumbersome it gets to > maintain. > the way i see it: > > * 1 repository > + easiest to maintain > + easiest to share > - not good for files with private stuff > - on some machines, you will check out stuff you don't need > * multiple fake git repositories > - harder to maintain (you need an additional command before you can work in > the repo) > - harder to share (you now have several repos) > + better for sharing private stuff (just don't share the ones containing > anything private), although not ideal (you might want to share the config > files, just not the password) > + you can avoid checking out useless (though unharmful) stuff on machines > which need a minimal $HOME. > > do you create additional fake git repositories for programs that might not > need it? why? > $ find ~ -maxdepth 1 -type d -name '.*' | wc -l > 98 > --> 98 dot-directories == 98 fake git repositories? > > some alternative ideas for the "private stuff" problem: > * why not create 1 git repository in which you commit your files, *except* > those files containing private stuff (commit those in a separate repository, > or in a separate branch which you do not push) > * and/or run only applications which can collect private stuff from a > dedicated file or "password manager" (or patch your apps) > > Dieter > _______________________________________________ > vcs-home mailing list > email@example.com > http://lists.madduck.net/listinfo/vcs-home _______________________________________________ vcs-home mailing list firstname.lastname@example.org http://lists.madduck.net/listinfo/vcs-home