On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote: > I would like to know > a use case or two to illustrate why there are symlinks pointing > at real files outside .git/refs/ hierarchy, and how that > arrangement is useful.
I've clearly laid out my case very badly. Here is the patch via sed $ sed -i -e '49s/lstat/stat/' refs.c It changes the do_for_each_ref function to follow symlinks blindly in both the pulling and fscking code. The usage I have is simple. I want to use git to give me a personal versioned filesystem of all my current working data. My problems are twofold. First, it is not obvious where the divisions between projects should be --- for the most part, this is not distributable software, but a haphazard collection of one-time code, and various other material that still benefits from version control. An all inclusive, time-based commit of the entire directory structure turns out to be quite useful. Obviously this use will never be anything but a personal store of data. Secondly, I have ambitions for some of the software I put together. These invariably are small projects that may or may not ever become distributable. Clearly they require their own commit history, yet given their immature state it seems hard to justify their own objects directory with its 256 directories for a few kilobytes of code. Given the existence of the GIT_OBJECT_DIRECTORY environment variable, it is a natural step to sharing a single object store amongst the small tightly-focused projects and the all-encompassing but unmanaged outermost directory which already is tracking the contents of the contained projects but knows nothing of their commit history. Implementing a commit tool to do this is actually very easy. All you need do is walk up the chain of parent directories from your working directory, noting the .git directories, until you reach one that has an .git/objects directory then set up the environment appropriately. The only catch is the necessity of maintaining the common object directory. The outermost .git directory needs refs to the contained subprojects commit histories that it honours in fsck-cache if it is not to silently delete them the next time you prune the repository. Symlinking in the refs/heads directories of all subprojects is the most straightforward way to achieve this as it automatically does the right thing with very little maintainance. It also keeps the real refs/heads of the subprojects' commit histories properly localized in the subprojects where they belong. It seems to me that having created the GIT_OBJECT_DIRECTORY hook, it only makes sense to follow symlinks in the refs directories. Matt --- http://free.draisey.ca P.S. This email is a bit long-winded so I didn't CC it to the mailing list. - 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
