From: Nguyen Thai Ngoc Duy Date: Tue, 17 Jan 2012 01:55:28 GMT Subject: Re: git grep doesn't follow symbolic link Message-ID: In-Reply-To: <7vwr8ruv1j.fsf@alter.siamese.dyndns.org> On Tue, Jan 17, 2012 at 5:44 AM, Junio C Hamano wrote: > Nguyen Thai Ngoc Duy writes: > >> 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? OK resolving links to untracked contents is bad and should only be supported in --no-index case, resolving links to tracked contents should be ok in principal? (I'm not sure how messed up diff code could be with these changes) -- Duy