git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: ltuikov@yahoo.com
Cc: git@vger.kernel.org
Subject: Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob
Date: Tue, 11 Jul 2006 23:16:40 -0700	[thread overview]
Message-ID: <7v64i31h6f.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20060712034345.14009.qmail@web31802.mail.mud.yahoo.com> (Luben Tuikov's message of "Tue, 11 Jul 2006 20:43:45 -0700 (PDT)")

Luben Tuikov <ltuikov@yahoo.com> writes:

> Teach tree->raw to not require the hash of the blob, but to
> figure it out from the file name.  This allows to externally
> link to files into the repository, such that the hash is not
> required.  I.e. the file obtained would be as of the HEAD
> commit.
>
> In contrast tree->blob for binary files passes the hash, as
> does tree->blob->plain for "text/*" files.
>
> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
> ---
>  gitweb/gitweb.cgi |   20 ++++++++++++++++----
>  1 files changed, 16 insertions(+), 4 deletions(-)

This has exactly the same line number problem.

@@ -1678,8 +1690,7 @@ sub git_tree {
 			      $cgi->a({-href => "$my_uri?" . esc...
 #			      " | " . $cgi->a({-href => "$my_uri...
 			      " | " . $cgi->a({-href => "$my_uri...
-			      " | " . $cgi->a({-href => "$my_uri...
+			      " | " . $cgi->a({-href => "$my_uri...
 			      "</td>\n";
 		} elsif ($t_type eq "tree") {
 			print "<td class=\"list\">" .

You are removing one line and adding one line, so the number of
old and new lines better match.

Hand-applied, tried, got confused and dropped.

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, 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.

BTW, can somebody volunteer to be a gitweb/ "subsystem
maintainer"?

  reply	other threads:[~2006-07-12  6:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-12  3:43 [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob Luben Tuikov
2006-07-12  6:16 ` Junio C Hamano [this message]
2006-07-12  8:32   ` Jakub Narebski
2006-07-12 18:02     ` Luben Tuikov
2006-07-12 18:12       ` Jakub Narebski
2006-07-12 17:52   ` Luben Tuikov
2006-07-14  5:49     ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2006-07-13  3:31 Luben Tuikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v64i31h6f.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=ltuikov@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).