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: vcs-home@lists.madduck.net <vcs-home@lists.madduck.net>
> 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://www.mail-archive.com/vcs-home@lists.madduck.net/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
> vcs-home@lists.madduck.net
> http://lists.madduck.net/listinfo/vcs-home
_______________________________________________
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Reply via email to