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 15, 2005, 08:12 UTC
Message-ID
<1124093522.721.41.camel@della.draisey.ca>
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
Show 18 quoted lines
> Matt Draisey <mattdraisey@sympatico.ca> writes:
> 
> > The behaviour of the symlinked in ref directories has changed from
> > earlier versions of git.  They used to be taken into account in
> > git-fsck-cache --unreachable.
> >
> > Can the previous behaviour be reinstated?
> 
> I would not have much problem accepting a patch for that; it
> would make things safer when a symlink points to a real file
> that is outside .git/refs/ that holds a pointer to a valid
> object.
> 
> Having said that, I would first like to know why you have a
> symlink there, and the real file pointed by it outside .git/refs
> hierarchy.  The core GIT tools do not create such symlinks, so
> either you are creating one by hand, or your Porcelain is
> creating one for you for whatever reason.

It is my own home-grown Porcelain that creates the symlinks. I've thrown together a python programme to track a nested collection of projects. My own programming efforts rarely exceed two or three files per project, and don't justify there own .git/objects repository. Still, a few projects do benefit from having their own commit history, while the rest are tracked as one big outermost superproject of unrelated stuff.

> 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.
Whether or not its useful??  Hmmm.  Debatable.

I've only written a commit tool. All the other git and cogito tools I invoke from the outermost directory like so 

$git-cat-file commit per/Minesweeper/master

Symlinking still works here as expected. The per directory is just there so I don't stomp on the outermost namespace, the Minesweeper is a symlink to the nested project's refs directory. Symlinking seems the natural way to do this as they only need updating when I move subdirectories around.

P.S. $echo new-id > .git/per/Minesweeper/master is safe here --- this is the actual behaviour I want.

Message 1 of 1 in “Re: symlinked directories in refs are now unreachable”
  1. Matt DraiseyAug 15, 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.