On Tue, Jan 17, 2012 at 5:44 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html