Re: git grep doesn't follow symbolic link

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 17, 2012, 06:44 UTC
Message-ID: <7v7h0qu8t8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8B9AGuRSx_5P22TOsqrA1rTEjQb78NN7PcTuK53iUmP_w@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> 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.