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
Matt --- http://free.draisey.ca
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