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.