Re: git grep doesn't follow symbolic link

Nguyen Thai Ngoc Duy [off-list ref] writes:

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?

Conceptually it is not as bad, but I doubt it is still "ok".

It would defeat one of the fundamental properties of Git (or any content
based revision control scheme for that matter): a tree object records the
hash of its contents, so if two subtrees agree at the content hash level,
you do not have to descend into them to compare what they contain.

Imagine that you have a symlink at a/b/c/d that points a file e at the
root level, and you are running "git log a/b/c".  Even if the entire
hierarchy a/ does not change in a commit since its parent, you may have to
show a/b/c/d only because "e" has changed.

So I suspect that the required change would involve a lot more than a
naïve "when we reach the leaf level, if it is a symlink, read the link
contents and call get_tree_entry() to dereference the blob, or if the link
points outside the tree, use 0{40} to say 'contents undefined'".

After you compare 'a' of parent and child and find them to be identical,
you still need to anticipate that the hierarchy _might_ have a symbolic
link somewhere deep inside, and read _everything_ at least once in order
to find symbolic links and where they point at (if you did that to parent
already, and if you know that the child agrees with it at 'a', then you
can obviously do not have to read everything in the child---you know the
parent and the child have the same _contents_ in 'a' at that point). And
then grab the pointee out of parent tree and child tree to compare.

I personally do not think it is worth it.