threads / patch / 5698

patchgitweb: "raw" links to blobs at HEAD

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

## tl;dr

5 messages between Sep 26, 2006 and Sep 26, 2006. Diffs are folded; open one to read it.

replies: 4people: 3as markdown or json

Luben Tuikov· Sep 26, 2006, 05:39 UTC · lore

Currently there is no HTML interface which references (or can be externally referenced) to yield a _binary_ blob at HEAD. There is one for non-binary blobs, but none for binary ones.

The reason is that "blob"/entry itself for non-binary entries gives you the "Blob page" where you can click on last link of the page path, but clicking on the binary entry/"blob" gives you the raw file.

Binary blobs:
  Since "raw" == the entry itself, we can eliminate this
redundancy and set "raw" to the binary blob at HEAD. This
patch implements that.  If the user wants the binary blob at
hash/hash_base then they can click on the entry itself.
Non-binary blobs:
  With this patch "raw" yields the HEAD revision as per the
above comment for binary blobs.  If the raw output of the
hash/hash_base blob is required the user can click on the entry
(same as for binary only) and then click on "raw" (which
used to be named "plain" not so long ago) or last entry of
"page" path.

Compare the "raw" link for non-binary blobs from tree view, to the alternative to getting it: click on entry->HEAD->last entry of "page" path.

Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
 gitweb/gitweb.perl |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)
Show changes to gitweb/gitweb.perl +3 −3
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c7ab3b6..959e3f9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1625,9 +1625,9 @@ sub git_print_tree_entry {
 			              "history");
 		}
 		print " | " .
-		      $cgi->a({-href => href(action=>"blob_plain",
-		                             hash=>$t->{'hash'}, file_name=>"$basedir$t->{'name'}")},
-		              "raw");
+			$cgi->a({-href => href(action=>"blob_plain", hash_base=>"HEAD",
+					       file_name=>"$basedir$t->{'name'}")},
+				"raw");
 		print "</td>\n";
 
 	} elsif ($t->{'type'} eq "tree") {
-- 
1.4.2.1.gdbbb
Junio C Hamano· Sep 26, 2006, 06:46 UTC · re: Luben Tuikov · lore

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.

Luben Tuikov· Sep 26, 2006, 18:53 UTC · re: Junio C Hamano · lore

Re: [PATCH] gitweb: "raw" links to blobs at 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
Jakub Narebski· Sep 26, 2006, 08:58 UTC · re: Luben Tuikov · lore

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

Luben Tuikov wrote:
> Currently there is no HTML interface which references (or
> can be externally referenced) to yield a _binary_ blob at
> HEAD.  There is one for non-binary blobs, but none for
> binary ones.

You can in the same number of steps. First go to _tree_ at head, then click on "raw" link.

It's true that decision that binary files are automatically redirected to "plain" ("raw") format, so they don't have "html" output caused that there is no link for binary blob at head. But I don't think that changing "raw" link to link to HEAD version, while all other links are to current version is a good idea...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Luben Tuikov· Sep 26, 2006, 20:20 UTC · re: Jakub Narebski · lore

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

--- Jakub Narebski <jnareb@gmail.com> wrote:
Show 9 quoted lines
> Luben Tuikov wrote:
> 
> > Currently there is no HTML interface which references (or
> > can be externally referenced) to yield a _binary_ blob at
> > HEAD.  There is one for non-binary blobs, but none for
> > binary ones.
> 
> You can in the same number of steps. First go to _tree_
> at head, then click on "raw" link.
Jakub,

For binary only files, there is no HTML interface to refer to, such that, hb=HEAD for _binary_ only files. Unless of course one types that on the URL line manually.

That is, I'd like to externally reference binary only blobs at "HEAD", s.t. no matter _when_ the reference is used, it would refer to the latest "version" of that file.

E.g. a PDF spec file.
My recent patches on the subject enable this capability.
    Luben
Show 17 quoted lines
> It's true that decision that binary files are automatically
> redirected to "plain" ("raw") format, so they don't have "html"
> output caused that there is no link for binary blob at head.
> But I don't think that changing "raw" link to link to HEAD
> version, while all other links are to current version is
> a good idea...
> -- 
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

← back to recent threads