In order to minimize the amount of files which need to be backed up, I decided to create an "upstream" repository which contains nothing but Linus's tree, which I packed into a single pack file, and which I would then only update every 3-6 months. The git tree(s) that I would use for Linux hacking would then use the upstream repository as an alternate source of objects. That way the "git gc" command is much faster, and it doesn't end up thrashing the main pack file found in the "upstream" repository (which is currently about 135 megs). This streamlines my backups a tad (every little bit helps). The only real problem with this is that I don't really need to have a working directory in the "upstream" repository, so I decided to try using a "bare repository". This is only barely (sorry) documented in the git Documentation, where in the git-clone manpage there is a description of how the administrative files end up in the top-level directory instead of the .git subdirectory. What isn't documented is what commands actually can deal with a bare repository. At the moment, it looks like a bare repository can be a target of a git pull, push, and merge commands, and it can be a source for a git clone, but that seems to be about it. All other commands, such as "git log" blow up with the error message "Not a git repository". This to me seems a bit lame, since why isn't a "bare repository" also a "git repository"? All of the information is there for "git log" to work. Commands that require a working directory obviously can't work, but there are plenty of git commands for which there's no reason why they shouldn't be able to operate on a bare repository. For example, "git repack", "git log", "git fetch", etc. So as a suggestion, it would be good if exactly what you can and can't use a "bare repository" for were documented. If it really is push, pull, fetch, and clone, I'll happily submit a patch to enhance the documentation accordingly. The next obvious question, though, is *should* that be all that works? A somewhat squinky hack that works quite nicely is to create a symlink from . to .git in the bare repository. At this point "git log", "git fetch", "git repack", etc., all start working. Of course, commands such as "git status" that involve a working directory will be pretty confused, but maybe we could fix that. What if we were to change "git clone --bare" to create the .git -> . symlink, and then add a check to commands that require a working directory to see if ".git" is a symlink to ., and if so, give an error message, "operation not supported on bare repository"? - Ted - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html