On 02/17/2015 10:57 PM, Junio C Hamano wrote: > Michael Haggerty <mhag...@alum.mit.edu> writes: > >> On 02/17/2015 05:55 PM, Jeff King wrote: >>> On Tue, Feb 17, 2015 at 05:39:27PM +0100, Michael Haggerty wrote: >>> >>>> There's a bunch of code in refs.c that is there explicitly for reading >>>> loose references that are symlinks. If the link contents literally start >>>> with "refs/", then they are read and treated as a symbolic ref. >>>> Otherwise, the symlink is just followed. >>> ... >> Yes, this makes sense too. But my point was that sticking symlinks to >> random files in your refs hierarchy is pretty questionable even *before* >> the symlink gets broken. If we would warn the user as soon as we saw >> such a thing, then the user's problem would never have advanced as far >> as it did. Do you think that emitting warnings on *intact* symlinks is >> too draconian? > > Do you mean that we would end up reading refs/heads/hold if the user > did this: > > git rev-parse --verify HEAD -- >precious > ln -s ../../../precious .git/refs/heads/hold > > because that symbolic link does not begin with "refs/",
Correct, you can do exactly that. The "hold" reference is resolvable and listable using "for-each-ref". But if I try to update it, the contents of the "precious" file are overwritten. On the other hand, if I run "pack-refs", then the current value of the "hold" reference is moved to "packed-refs" and the symlink is removed. This behavior is not sane. > and is an > accident waiting to happen so we should forbid it in the longer > term and warning when we see it would be the first step? Yes, I am proposing that approach, though if somebody can suggest a use case I'm willing to be convinced otherwise. The only thing I can imagine symlinks being useful for might be to temporarily create a fake repo, run one or two specific known-safe commands, then delete the repo again. Michael -- Michael Haggerty mhag...@alum.mit.edu -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
