Thanks for committing my one-character patch. In the commit message you said
> Come to think of > it, maybe we should disallow symlink inside .git/refs hierarchy; > we update the files there by creat/rename pair, so having > symlinks would not work anyway when you do anything that would > update them.] I agree, linking at the file level makes no sense --- create/rename pairs will clobber symlinked files (as they would for hardlinked files). If you accept their use at all, symlinked directories are the only way to go. The alternatives to symlinked directories are: (1) adding a command line option to fsck that supplies a path to an external refs directory (1a) adding a subtool to create a commandline list of sha from a supplied path to an external refs directory (2) adding an environment variable to do the same (3) adding a .git configuration file which contains a path --- this is just a userspace symlink (4) create a monster (refcounting objects?) (true cross-references?) (conservative garbage collectors that scan your entire hard disk for potential references) (I believe the same arguments hold for the pulling code as for fsck) Case (1) is easy to implement. (I whipped up a working patch yesterday) The hardest part is thinking up a good name for the command line argument. Case (1a) is too ugly. Both of these cases place a considerable burden on the user, and require some Porcelain work. Case (2) makes sense but is too intrusive for me to contemplate. I defer to a core developer. Case (3) offers no advantages over a symlinked directory under refs. Case (4) is probably patented by Microsoft. I like symlinks for their simplicity, and that they work now. Otherwise I am a really only submitting a feature request. Matt - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
