Re: [PATCH] gitweb: "raw" links to blobs at HEAD

This does not feel right.  Go to summary view, pick the tree
link of a non-head commit from the shortlog list, and the raw
links on the resulting page all say hb=HEAD.

Doesn't this make clicking the entry itself (blob view) and
clicking on the raw link (blob-plain view) inconsistent?  The
former goes to the blob from that revision while the latter
always goes to the HEAD.

--- Junio C Hamano <junkio@cox.net> wrote:

This does not feel right.  Go to summary view, pick the tree
link of a non-head commit from the shortlog list, and the raw
links on the resulting page all say hb=HEAD.

I see your point.

Doesn't this make clicking the entry itself (blob view) and
clicking on the raw link (blob-plain view) inconsistent?

It this exactly this consistency which the patch used to de-couple
it and use the "raw" to point to HEAD.

The former goes to the blob from that revision while the latter
always goes to the HEAD.

Yes, I completely understand the conundrum.

Ideally, hb would equal HEAD from the _context_, but
  1) hb and h != HEAD for any "raw" link,
  2) one can set hb=HEAD in the context only when the "blob page"
     can be loaded, which is impossible for binary blobs.

So the fix would be that, unless the user had selected a hb/h
explicitly, set "raw" to HEAD (i.e. by default), but leave the entry
with hb/h in SHA.  This way, one can take a reference to HEAD or
SHA of the head depending on what is needed.  And if they had
selected a hb/h explicitly then both the entry and the "raw"
would point to the SHA.

Such a patch can go on top of those two.

    Luben