Re: [PATCH 3/3] t3600: test rm of path with changed leading symlinks
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 4, 2013, 20:31 UTC
- Message-ID
- <7v1uaqhwb4.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130404195554.GA20823@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 14 quoted lines
>> If you do this: >> >> rm -fr d e >> mkdir e >> >e/f >> ln -s e d >> git add d/f >> >> we do complain that d/f is beyond a symlink (meaning that all you >> can add is the symlink d that may happen to point at something). > > Right, but that is because you are adding a bogus entry to the index; we > cannot have both 'd' as a symlink and 'd/f' as a path in our git tree. > But in the removal case, the index manipulation is perfectly reasonable.
I think you misread me. I am not adding 'd' as a symlink at all. IIRC, ancient versions of Git got this case wrong and added d/f to the index, which we later fixed.
I have been hinting that we should do the same safety not to touch (even compare the contents of) e/f, because the only reason we even look at it is because it appears beyond a symbolic link 'd'.