(Pang's patch [1] caught my attention so I returned to the original discussion) [1] http://thread.gmane.org/gmane.comp.version-control.git/188552 On Wed, Jan 11, 2012 at 1:22 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Thomas Rast <trast@xxxxxxxxxxxxxxx> writes: > >>> 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. That's a good default. But git should allow me to say "diff the files that symlinks point to". Link target is content from git perspective, not from user perspective. So instead changing the default behavior specifically for git-grep as Pang did, I think adding --follow-symlinks option, that could be passed to grep or any of diff family, would be a better approach. -- 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