{"thread":{"id":"1514","subject":"Re: symlinked directories in refs are now unreachable","startedAt":"2005-08-15T08:12:02Z","lastAt":"2005-08-15T08:12:02Z","messageCount":1,"participants":["Matt Draisey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7277","messageId":"1124093522.721.41.camel@della.draisey.ca","threadId":"1514","inReplyTo":null,"subject":"Re: symlinked directories in refs are now unreachable","fromName":"Matt Draisey","fromEmail":"mattdraisey@sympatico.ca","sentAt":"2005-08-15T08:12:02Z","receivedAt":"2005-08-15T08:12:02Z","isPatch":false,"sender":{"key":"matt@draisey.ca","avatar":null},"body":"On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:\n> Matt Draisey <mattdraisey@sympatico.ca> writes:\n> \n> > The behaviour of the symlinked in ref directories has changed from\n> > earlier versions of git.  They used to be taken into account in\n> > git-fsck-cache --unreachable.\n> >\n> > Can the previous behaviour be reinstated?\n> \n> I would not have much problem accepting a patch for that; it\n> would make things safer when a symlink points to a real file\n> that is outside .git/refs/ that holds a pointer to a valid\n> object.\n> \n> Having said that, I would first like to know why you have a\n> symlink there, and the real file pointed by it outside .git/refs\n> hierarchy.  The core GIT tools do not create such symlinks, so\n> either you are creating one by hand, or your Porcelain is\n> creating one for you for whatever reason.\n\nIt is my own home-grown Porcelain that creates the symlinks.  I've\nthrown together a python programme to track a nested collection of\nprojects.  My own programming efforts rarely exceed two or three files\nper project, and don't justify there own .git/objects repository.\nStill, a few projects do benefit from having their own commit history,\nwhile the rest are tracked as one big outermost superproject of\nunrelated stuff.\n\n> I would like to know\n> a use case or two to illustrate why there are symlinks pointing\n> at real files outside .git/refs/ hierarchy, and how that\n> arrangement is useful.\n\nWhether or not its useful??  Hmmm.  Debatable.\n\nI've only written a commit tool.  All the other git and cogito tools I\ninvoke from the outermost directory like so \n\n$git-cat-file commit per/Minesweeper/master\n\nSymlinking still works here as expected.  The per directory is just\nthere so I don't stomp on the outermost namespace, the Minesweeper is a\nsymlink to the nested project's refs directory.  Symlinking seems the\nnatural way to do this as they only need updating when I move\nsubdirectories around.\n\nP.S. $echo new-id > .git/per/Minesweeper/master is safe here --- this is\nthe actual behaviour I want.\n"}]}