git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: symlinked directories in refs are now unreachable

From
MDMatt Draisey <mattdraisey@sympatico.ca>
Date
Aug 17, 2005, 00:53 UTC
Message-ID
<1124171194.762.74.camel@della.draisey.ca>
In-Reply-To
<1124089116.749.39.camel@della.draisey.ca>
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.

Previous: Matt DraiseyNext: Junio C Hamano
Message 5 of 9 in “symlinked directories in refs are now unreachable”
  1. Matt DraiseyAug 15, 2005
  2. Linus TorvaldsAug 15, 2005
  3. Junio C HamanoAug 15, 2005
  4. Matt DraiseyAug 15, 2005
  5. Matt DraiseyAug 17, 2005
  6. Junio C HamanoAug 16, 2005
  7. Matt DraiseyAug 15, 2005
  8. Junio C HamanoAug 17, 2005
  9. Matt DraiseyAug 18, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.