Re: git grep doesn't follow symbolic link

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 16, 2012, 22:44 UTC
Message-ID: <7vwr8ruv1j.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8CaBAEJo_LuvjYhb2kfofH83cbR5DFDffmmCU3uJFqk+g@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

Show 9 quoted lines

> It's not wrong per se. It's an implication that users have to take
> when they choose to use it. We may help make it clear that the
> symlinks point to untracked files by putting some indication in the
> diff.
>
> When I do "git log -Sfoo -- '*.cxx'" I don't really care if bar.cxx is
> a symlink. Neither does my compiler. It may be a symlink's target
> change that makes "foo" appear. Git could help me detect that quickly
> instead of sticking with tracked contents only.

As there is nothing in Git that tells that whatever is pointed at by bar.cxx that happens to be in your filesystem today had "foo" in it when that historical version of the commit whose bar.cxx symlink was updated to point to that file. It is *WRONG* to show the commit as something that changes bar.cxx to contain "foo" (or more precisely, changes the count of "foo" in it).

Why is it so hard to understand?