Matt Draisey <[EMAIL PROTECTED]> 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. 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. - 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
