Luben Tuikov <ltuikov@xxxxxxxxx> writes:
>> I think _allowing_ to accept filename not hash is a sane change,
>> and would be useful if you want to allow linking to always the
>> HEAD version from external sites,
>
> Indeed, it is useful.
>
>> but I do not think listing the
>> raw link in the tree view without the hash is a good idea. It
>> makes things quite confusing that "blob" link in its
>> neighbourhood gives the blob from that specific version, but
>> "raw" gives the version from HEAD, even when you are browsing
>> something other than HEAD.
>
> I just thought it to be an easy place to put the "raw"-no-hash
> link.
>
> BTW, Junio, it would be a shame to lose this capability. How
> would you like to proceed with this? Where would you like to
> see this kind of link go?
My preference?
Allowing to link the HEAD version from an _external_ source is
useful (i.e. you can put a link in gitwiki to point at a file
and say "the latest is always available at this URL").
We already support these:
a=blob&f=README
a=blob&f=README&hb=HEAD
a=blob&f=README&hb=HEAD~20
but not these:
a=blob_plain&f=README
a=blob_plain&f=t/test4012.png
The last example that does not generate text is less of a
problem, thanks to your previous patch, because "sub git_blob"
supports the "filename with or without hash base" syntax and
sends the correct hash to git_blob_plain to fall back, but that
does not help for text files. This patch corrects that, which
is nice.
However, I do not think the change to "sub git_tree" makes much
sense. The links within gitweb-generated pages are about
browsing the history. As I already said, having <blob> link
that is history specific and <raw> link which is not (iow always
goes to HEAD) next to each other is confusing, and you are
making it less easy to get a raw output from a specific version
because you removed that feature from the link and replaced it
with something less useful.
If somebody wants to see what the latest version of a blob looks
like while browsing the history with gitweb, I think it is a
more natural workflow to go to <history> link and find the
latest version. So maybe you might want to add <raw> link in
the output of the history action?
Side note: right now, <history> link does not show any
history newer than the commit that has the link itself;
maybe there is a room for improvement there but we need
to be careful not to trash the webserver caching.
Obviously you could go back to the repository top page and start
digging the latest tree from the top, but that is a bit more
cumbersome.
-
: 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