Re: [PATCH] gitweb: Better symbolic link support in "tree" view

From: Junio C Hamano <junkio@cox.net>
Date: Dec 5, 2006, 22:34 UTC
Message-ID: <7vk616ezu5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200612052227.56770.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 10 quoted lines

> Junio C Hamano wrote:
>> ...
>> I think " -> link_target" is fine, but I do not know if it is
>> useful (while I do not think it is wrong) to make the value that
>> would have been returned from readlink() into an href, even when
>> it points at something inside the same revision.
>
> I have added this bit (making symbolic link target symlink) because 
> otherwise there is no way, besides hand-munging the URL, to go to the 
> link target.

I can read what you wrote it does.

For one thing, the user is tracking the symbolic link itself, not the contents of the file or directory the link points at. For that "tracked symlink", where it points at is the important content, not what the file that is pointed at happens to contain in the same revision.

If you have to open an extra object while drawing the list, I do not think it is worth doing it.

In order to show " -> link_target", you have to read the contents of the blob. I think that overhead to read one extra blob is probably an acceptable tradeoff for convenience.

But if you want to make it a link into the same tree, you would need to check if link_target path exists and if it is a blob or tree to produce an appropriate tree_view/blob_view link (I haven't read your code but that is the natural thing to do).

That would involve in reading a few more tree objects (depending on how deep the target is in the tree), and I do not think it is worth doing it while drawing a list. After you prepared dozens of such links, the user would click at most one of them and leaves the page; your cycles to draw those unclicked links were wasted.

If you wanted to do this, a better way would be to have a new view that takes a commit/tree object and a path from the top of the repository, and shows either "no such path in that tree" or "here is the view for that object, by the way it was a blob." page. Then your list drawing would still need to open each symlink blob to show " -> link_target", and need to check if it goes outside the repository (I would assume you are handling relative links as well), but you do not need to do expensive ls-tree step one per symlink on the page. The href attr of the A element " -> link_target" would point at that "universal object view" with the link_target pathname (that is, the blob contents) and the commit/tree object name (h or hb I do not know which) and you will spend cycles to run ls-tree only when the user actually asks to follow that link.

In other words, I think trying to be lazy is extremely important while drawing a big list.