Re: git grep doesn't follow symbolic link

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 10, 2012, 18:22 UTC
Message-ID: <7vwr8za04q.fsf@alter.siamese.dyndns.org>
In-Reply-To: <877h0zlvwd.fsf@thomas.inf.ethz.ch>

Thomas Rast <trast@student.ethz.ch> writes:

Show 5 quoted lines

>> I'd imagine so: symbolic links are not portable across different file
>> systems; Git's internal representation of a symbolic link is a file
>> containing the path of the file to be linked to.
>
> I'd actually welcome a fix to this general area,...

Even though some platforms may lack symbolic links, where they are supported, they have a clear and defined meaning and that is what Git tracks as contents: where the link points at.

So we would want our "git diff" to tell us, even if you moved without content modification the symbolic link target that lives somewhere on your filesystem but is outside the control of Git, and updated a symbolic link that is tracked by Git to point to a new location, that you updated the link. On the other hand, if you did not update a tracked symbolic link, even if the location the link points at that may or may not be under the control of Git, we do not want "git diff" to show anything. As far as that link is concerned, nothing has changed.

Changing this would not be a fix; it would be butchering.

Having said that...

> But I lose all the cute features of git-diff.  I *could* say
>
>   git diff --no-index <(ls) <(cd elsewhere && ls)

... "--no-index" is specifically _not_ about tracked contents of Git, but was bolted on as a poor-man's substitute for GNU diff (think of it as somebody wanted to have the nifty "git diff" features like renames and coloring, but did not want to bother to port them to GNU diff codebase, but instead hacked Git codebase to work outside Git tracked contents). In that context, I would agree that it _might_ make sense to treat special files and symbolic links in a way that is different from how tracked contents are handled.