Re: fake git repositories.. how far do you go?
also sprach martin f krafft [2011.04.06.1040 +0200]: > "detached bare" would be better. Actually, see http://lists.madduck.net/pipermail/vcs-home/2011-April/000378.html Sorry, -- martin | http://madduck.net/ | http://two.sentenc.es/ "the surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently." -- friedrich nietzsche spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Fw: fake git repositories.. how far do you go?
also sprach Dieter Plaetinck [2011.03.03.0953 +0100]: > I could not really understand why one would actually _want_ > multiple fake git repositories. When I commit a change to my vim configuration, that has nothing to do with the history of changes to my mutt configuration. Thus, I prefer to keep them separate, and Git lets me do that. Now I can share each configuration on git.madduck.net and people can clone just the parts they want. In short: because I can, and tools like vcsh and mr and all the others make it a little less cumbersome. But if you prefer to use a single repo for your homedir stuff, do it. -- martin | http://madduck.net/ | http://two.sentenc.es/ "if beethoven's seventh symphony is not by some means abridged, it will soon fall into disuse." -- philip hale, boston music critic, 1837 spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: fake git repositories.. how far do you go?
also sprach Dieter Plaetinck [2011.03.03.1416 +0100]: > I meant "fake bare git repositories". I just try to stick to the > existing terminology. see the articles I linked to, where the > concept is explained in detail. "detached bare" would be better. -- martin | http://madduck.net/ | http://two.sentenc.es/ "the duration of passion is proportionate with the original resistance of the woman." -- honoré de balzac spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: fake git repositories.. how far do you go?
On Thu, 3 Mar 2011 12:21:44 + seanh wrote: > 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. Yep, I agree. It's just that I had the impression from Martins' and Penny's posts they implied using fake bare git repo's for pretty much every single directory/application, or maybe I missed something. > 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. I work the other way around, which is much simpler: I add all directories that contain executables I like to my PATH. So my $PATH contains a lot of code/project_foo directories. It means I cannot leave project code in a broken state, but in practice, this didn't turn out to be a problem. > 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. Hmm, this seems a bit complicated to me. So for every such code project, you add it as submodule to your main repo, *and* you need to make symlinks for all executables in such submodules? > 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 interesting, i've now also switched to a submodule/pathogen-based vim setup (forked from some else actually, https://github.com/Dieterbe/vimfiles) Dieter ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: fake git repositories.. how far do you go?
On Thu, 3 Mar 2011 11:26:51 - hessi...@hessiess.com wrote: > I don't really get what you mean by ``fake'' git repos. Multiple repos > does not make them any less real. > > Anyway, I have one repo for my dot files. And a few others for logically > independent entities. Programming projects go in there own repos, my > writing is in its own repo etc. > > Private dot files are stored in a strongly encrypted tarball, which is > checked into git. By doing that you loose any ability to track and merge > per-file changes, but it has not been a problem in my experience. > > Also, only version the files that you absolutely need. Most dot files are > auto-generated and store nothing of value. I only version my vim config > file, ssh keys(encrypted) and a few other bits and paces. > > Robert I meant "fake bare git repositories". I just try to stick to the existing terminology. see the articles I linked to, where the concept is explained in detail. Dieter ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Fw: fake git repositories.. how far do you go?
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 > To: 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 c
Re: Fw: fake git repositories.. how far do you go?
I don't really get what you mean by ``fake'' git repos. Multiple repos does not make them any less real. Anyway, I have one repo for my dot files. And a few others for logically independent entities. Programming projects go in there own repos, my writing is in its own repo etc. Private dot files are stored in a strongly encrypted tarball, which is checked into git. By doing that you loose any ability to track and merge per-file changes, but it has not been a problem in my experience. Also, only version the files that you absolutely need. Most dot files are auto-generated and store nothing of value. I only version my vim config file, ssh keys(encrypted) and a few other bits and paces. Robert > anyone? > > > Begin forwarded message: > > Date: Tue, 22 Feb 2011 21:49:24 +0100 > From: Dieter Plaetinck > To: 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
Fw: fake git repositories.. how far do you go?
anyone? Begin forwarded message: Date: Tue, 22 Feb 2011 21:49:24 +0100 From: Dieter Plaetinck To: 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
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
