On Thu, Nov 10, 2016 at 7:23 AM, Jeff King <peff@xxxxxxxx> wrote: > On Wed, Nov 09, 2016 at 04:18:29PM -0800, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >> > On Wed, Nov 09, 2016 at 02:58:37PM -0800, Junio C Hamano wrote: >> > >> > I'm slightly confused. Did you mean "supporting any in-tree symlink to >> > an out-of-tree destination" in your first sentence? >> >> I was trying to say that these "control files used solely by git" >> have no business being a symbolic link pointing at anywhere, even >> inside the same tree; actually, especially if it is inside the same >> tree. > > OK. That is what my patch does (modulo .gitmodules, which I did not > think of). But I think that is the opposite of Duy's opinion, as his > review seemed to object to that. I only objected the rationale (to be consistent with reading index). If you sold it as malicious symlinks, or even put it like Junio "no, the design makes more sense to be this way", I would be ok. On the implementation side, we should print something friendlier than strerror(ELOOP) if we decide that "symlinks on .git* files are wrong". The standard ELOOP message does not communicate our design decision well to the users. But this is a minor thing and can be ignored. > As you know my ulterior motive is dealing with malicious out-of-tree > symlinks, and I would be happy to deal with that directly. That still > leaves symlinked ".gitmodules" etc in a funny state (they work in the > filesystem but not in the index), but since nobody is _complaining_, > it's a bug we could leave for another day. The discussion trailed off a bit to symlinks in general in worktree too, I think. But it's not my itch, we can leave it for another day. -- Duy