{"thread":{"id":"4857","subject":"[PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob","startedAt":"2006-07-12T03:43:45Z","lastAt":"2006-07-14T05:49:06Z","messageCount":7,"participants":["Luben Tuikov","Junio C Hamano","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"23683","messageId":"20060712034345.14009.qmail@web31802.mail.mud.yahoo.com","threadId":"4857","inReplyTo":null,"subject":"[PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-07-12T03:43:45Z","receivedAt":"2006-07-12T03:43:45Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"Teach tree->raw to not require the hash of the blob, but to\nfigure it out from the file name. This allows to externally\nlink to files into the repository, such that the hash is not\nrequired. I.e. the file obtained would be as of the HEAD\ncommit.\n\nIn contrast tree->blob for binary files passes the hash, as\ndoes tree->blob->plain for \"text/*\" files.\n\nSigned-off-by: Luben Tuikov \n---\n gitweb/gitweb.cgi | 20 ++++++++++++++++----\n 1 files changed, 16 insertions(+), 4 deletions(-)\n\n\ndiff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi\nindex 2e87de4..e904eb7 100755\n--- a/gitweb/gitweb.cgi\n+++ b/gitweb/gitweb.cgi\n@@ -1521,6 +1521,14 @@ sub git_blob_plain_mimetype {\n }\n \n sub git_blob_plain {\n+\tif (!defined $hash) {\n+\t\tif (defined $file_name) {\n+\t\t\tmy $base = $hash_base || git_read_head($project);\n+\t\t\t$hash = git_get_hash_by_path($base, $file_name, \"blob\") || die_error(undef, \"Error lookup file.\");\n+\t\t} else {\n+\t\t\tdie_error(undef, \"No file name defined.\");\n+\t\t}\n+\t}\n \tmy $type = shift;\n \topen my $fd, \"-|\", \"$gitbin/git-cat-file blob $hash\" or die_error(\"Couldn't cat $file_name, $hash\");\n \n@@ -1544,9 +1552,13 @@ sub git_blob_plain {\n }\n \n sub git_blob {\n-\tif (!defined $hash && defined $file_name) {\n-\t\tmy $base = $hash_base || git_read_head($project);\n-\t\t$hash = git_get_hash_by_path($base, $file_name, \"blob\") || die_error(undef, \"Error lookup file.\");\n+\tif (!defined $hash) {\n+\t\tif (defined $file_name) {\n+\t\t\tmy $base = $hash_base || git_read_head($project);\n+\t\t\t$hash = git_get_hash_by_path($base, $file_name, \"blob\") || die_error(undef, \"Error lookup file.\");\n+\t\t} else {\n+\t\t\tdie_error(undef, \"No file name defined.\");\n+\t\t}\n \t}\n \tmy $have_blame = git_get_project_config_bool ('blame');\n \topen my $fd, \"-|\", \"$gitbin/git-cat-file blob $hash\" or die_error(undef, \"Open failed.\");\n@@ -1678,8 +1690,7 @@ sub git_tree {\n \t\t\t $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blob;h=$t_hash$base_key;f=$base$t_name\")}, \"blob\") .\n #\t\t\t \" | \" . $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blame;h=$t_hash$base_key;f=$base$t_name\")}, \"blame\") .\n \t\t\t \" | \" . $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=history;h=$hash_base;f=$base$t_name\")}, \"history\") .\n-\t\t\t \" | \" . $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blob_plain;h=$t_hash;f=$base$t_name\")}, \"raw\") .\n+\t\t\t \" | \" . $cgi->a({-href => \"$my_uri?\" . esc_param(\"p=$project;a=blob_plain;f=$base$t_name\")}, \"raw\") .\n \t\t\t \"\\n\";\n \t\t} elsif ($t_type eq \"tree\") {\n \t\t\tprint \"\" .\n-- \n1.4.1.g9ca3\n\n"},{"id":"23692","messageId":"7v64i31h6f.fsf@assigned-by-dhcp.cox.net","threadId":"4857","inReplyTo":"20060712034345.14009.qmail@web31802.mail.mud.yahoo.com","subject":"Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-12T06:16:40Z","receivedAt":"2006-07-12T06:16:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> Teach tree->raw to not require the hash of the blob, but to\n> figure it out from the file name. This allows to externally\n> link to files into the repository, such that the hash is not\n> required. I.e. the file obtained would be as of the HEAD\n> commit.\n>\n> In contrast tree->blob for binary files passes the hash, as\n> does tree->blob->plain for \"text/*\" files.\n>\n> Signed-off-by: Luben Tuikov \n> ---\n> gitweb/gitweb.cgi | 20 ++++++++++++++++----\n> 1 files changed, 16 insertions(+), 4 deletions(-)\n\nThis has exactly the same line number problem.\n\n@@ -1678,8 +1690,7 @@ sub git_tree {\n \t\t\t $cgi->a({-href => \"$my_uri?\" . esc...\n #\t\t\t \" | \" . $cgi->a({-href => \"$my_uri...\n \t\t\t \" | \" . $cgi->a({-href => \"$my_uri...\n-\t\t\t \" | \" . $cgi->a({-href => \"$my_uri...\n+\t\t\t \" | \" . $cgi->a({-href => \"$my_uri...\n \t\t\t \"\\n\";\n \t\t} elsif ($t_type eq \"tree\") {\n \t\t\tprint \"\" .\n\nYou are removing one line and adding one line, so the number of\nold and new lines better match.\n\nHand-applied, tried, got confused and dropped.\n\nI think _allowing_ to accept filename not hash is a sane change,\nand would be useful if you want to allow linking to always the\nHEAD version from external sites, but I do not think listing the\nraw link in the tree view without the hash is a good idea. It\nmakes things quite confusing that \"blob\" link in its\nneighbourhood gives the blob from that specific version, but\n\"raw\" gives the version from HEAD, even when you are browsing\nsomething other than HEAD.\n\nBTW, can somebody volunteer to be a gitweb/ \"subsystem\nmaintainer\"?\n"},{"id":"23698","messageId":"e92c1e$lvk$1@sea.gmane.org","threadId":"4857","inReplyTo":"7v64i31h6f.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-07-12T08:32:23Z","receivedAt":"2006-07-12T08:32:23Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Luben Tuikov writes:\n> \n>> Teach tree->raw to not require the hash of the blob, but to\n>> figure it out from the file name. This allows to externally\n>> link to files into the repository, such that the hash is not\n>> required. I.e. the file obtained would be as of the HEAD\n>> commit.\n>>\n>> In contrast tree->blob for binary files passes the hash, as\n>> does tree->blob->plain for \"text/*\" files.\n\n> I think _allowing_ to accept filename not hash is a sane change,\n> and would be useful if you want to allow linking to always the\n> HEAD version from external sites, but I do not think listing the\n> raw link in the tree view without the hash is a good idea. It\n> makes things quite confusing that \"blob\" link in its\n> neighbourhood gives the blob from that specific version, but\n> \"raw\" gives the version from HEAD, even when you are browsing\n> something other than HEAD.\n> \n> BTW, can somebody volunteer to be a gitweb/ \"subsystem\n> maintainer\"?\n\nI think the change to raw aka. blob_plain and not to plain is because in\nplain view you have this HEAD link which takes us to HEAD revision of the\nfile (even if we are on different branch IIRC).\n\nWorkaround for either format is to remove 'h' (hash) parameter entirely, and \nput in 'hb' (hashbase aka headref aka branch) the branch name. Gitweb then\nshows the contents of latest version of the file.\n\nBTW. sometimes you want to link to specific version of the file, and\nsometimes to newest. I think it would be best (if possible, feasible, and\nnot too much resource consuming) that links from tree specified by hash be\nto specified by hash version of file, while links from tree specified by\nheadref and name only would have links to latest version of the file.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"23720","messageId":"20060712175220.73131.qmail@web31813.mail.mud.yahoo.com","threadId":"4857","inReplyTo":"7v64i31h6f.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-07-12T17:52:20Z","receivedAt":"2006-07-12T17:52:20Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> > Teach tree->raw to not require the hash of the blob, but to\n> > figure it out from the file name. This allows to externally\n> > link to files into the repository, such that the hash is not\n> > required. I.e. the file obtained would be as of the HEAD\n> > commit.\n> >\n> > In contrast tree->blob for binary files passes the hash, as\n> > does tree->blob->plain for \"text/*\" files.\n> >\n> > Signed-off-by: Luben Tuikov \n> > ---\n> > gitweb/gitweb.cgi | 20 ++++++++++++++++----\n> > 1 files changed, 16 insertions(+), 4 deletions(-)\n> \n> This has exactly the same line number problem.\n[cut]\n> Hand-applied, tried, got confused and dropped.\n\nI'll regenerate and send it to the list.\n\n> I think _allowing_ to accept filename not hash is a sane change,\n> and would be useful if you want to allow linking to always the\n> HEAD version from external sites,\n\nIndeed, it is useful.\n\n> but I do not think listing the\n> raw link in the tree view without the hash is a good idea. It\n> makes things quite confusing that \"blob\" link in its\n> neighbourhood gives the blob from that specific version, but\n> \"raw\" gives the version from HEAD, even when you are browsing\n> something other than HEAD.\n\nI just thought it to be an easy place to put the \"raw\"-no-hash\nlink.\n\nBTW, Junio, it would be a shame to lose this capability. How\nwould you like to proceed with this? Where would you like to\nsee this kind of link go?\n\n> BTW, can somebody volunteer to be a gitweb/ \"subsystem\n> maintainer\"?\n\nMake sure you pick someone liberal without personal aspirations\nor turning it into a personal crusade. Service to the community\n(not self, or company XYZ) is best.\n\n Luben\n"},{"id":"23721","messageId":"20060712180204.23953.qmail@web31801.mail.mud.yahoo.com","threadId":"4857","inReplyTo":"e92c1e$lvk$1@sea.gmane.org","subject":"Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-07-12T18:02:04Z","receivedAt":"2006-07-12T18:02:04Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Jakub Narebski wrote:\n> Junio C Hamano wrote:\n> \n> > Luben Tuikov writes:\n> > \n> >> Teach tree->raw to not require the hash of the blob, but to\n> >> figure it out from the file name. This allows to externally\n> >> link to files into the repository, such that the hash is not\n> >> required. I.e. the file obtained would be as of the HEAD\n> >> commit.\n> >>\n> >> In contrast tree->blob for binary files passes the hash, as\n> >> does tree->blob->plain for \"text/*\" files.\n> \n> > I think _allowing_ to accept filename not hash is a sane change,\n> > and would be useful if you want to allow linking to always the\n> > HEAD version from external sites, but I do not think listing the\n> > raw link in the tree view without the hash is a good idea. It\n> > makes things quite confusing that \"blob\" link in its\n> > neighbourhood gives the blob from that specific version, but\n> > \"raw\" gives the version from HEAD, even when you are browsing\n> > something other than HEAD.\n> > \n> > BTW, can somebody volunteer to be a gitweb/ \"subsystem\n> > maintainer\"?\n> \n> I think the change to raw aka. blob_plain and not to plain is because in\n> plain view you have this HEAD link which takes us to HEAD revision of the\n> file (even if we are on different branch IIRC).\n> \n> Workaround for either format is to remove 'h' (hash) parameter entirely, and \n> put in 'hb' (hashbase aka headref aka branch) the branch name. Gitweb then\n> shows the contents of latest version of the file.\n> \n> BTW. sometimes you want to link to specific version of the file, and\n> sometimes to newest. I think it would be best (if possible, feasible, and\n> not too much resource consuming) that links from tree specified by hash be\n> to specified by hash version of file, while links from tree specified by\n> headref and name only would have links to latest version of the file.\n\nYou seem to have hand-edited the mail headers to remove\nJunio and myself from the CC/To headers list, but leave git@vger.\n\nPlease don't do that. Just click Reply-All and continue with your\nmessage.\n\nThanks,\n Luben\n\nP.S. Restored.\n"},{"id":"23722","messageId":"8fe92b430607121112i56085730v6724235618e630c8@mail.gmail.com","threadId":"4857","inReplyTo":"20060712180204.23953.qmail@web31801.mail.mud.yahoo.com","subject":"Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-07-12T18:12:52Z","receivedAt":"2006-07-12T18:12:52Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 7/12/06, Luben Tuikov wrote:\n\n> You seem to have hand-edited the mail headers to remove\n> Junio and myself from the CC/To headers list, but leave git@vger.\n>\n> Please don't do that. Just click Reply-All and continue with your\n> message.\n\nNo, I've just replied from newsreader (not mail client) via GMane news\ninterface to git mailing list (gmane.comp.version-control.git), and I forgot\nto use Reply-All, i.e. use mail as well as news interface.\n\nBesides I seem to have problems trying to configure KNode to send\nmail, especially with mixed mail+news sending.\n-- \nJakub Narebski\n"},{"id":"23803","messageId":"7vhd1kspm5.fsf@assigned-by-dhcp.cox.net","threadId":"4857","inReplyTo":"20060712175220.73131.qmail@web31813.mail.mud.yahoo.com","subject":"Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-14T05:49:06Z","receivedAt":"2006-07-14T05:49:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n>> I think _allowing_ to accept filename not hash is a sane change,\n>> and would be useful if you want to allow linking to always the\n>> HEAD version from external sites,\n>\n> Indeed, it is useful.\n>\n>> but I do not think listing the\n>> raw link in the tree view without the hash is a good idea. It\n>> makes things quite confusing that \"blob\" link in its\n>> neighbourhood gives the blob from that specific version, but\n>> \"raw\" gives the version from HEAD, even when you are browsing\n>> something other than HEAD.\n>\n> I just thought it to be an easy place to put the \"raw\"-no-hash\n> link.\n>\n> BTW, Junio, it would be a shame to lose this capability. How\n> would you like to proceed with this? Where would you like to\n> see this kind of link go?\n\nMy preference?\n\nAllowing to link the HEAD version from an _external_ source is\nuseful (i.e. you can put a link in gitwiki to point at a file\nand say \"the latest is always available at this URL\").\n\nWe already support these:\n\n a=blob&f=README\n a=blob&f=README&hb=HEAD\n a=blob&f=README&hb=HEAD~20\n\nbut not these:\n\n a=blob_plain&f=README\n a=blob_plain&f=t/test4012.png\n\nThe last example that does not generate text is less of a\nproblem, thanks to your previous patch, because \"sub git_blob\"\nsupports the \"filename with or without hash base\" syntax and\nsends the correct hash to git_blob_plain to fall back, but that\ndoes not help for text files. This patch corrects that, which\nis nice.\n\nHowever, I do not think the change to \"sub git_tree\" makes much\nsense. The links within gitweb-generated pages are about\nbrowsing the history. As I already said, having link\nthat is history specific and link which is not (iow always\ngoes to HEAD) next to each other is confusing, and you are\nmaking it less easy to get a raw output from a specific version\nbecause you removed that feature from the link and replaced it\nwith something less useful.\n\nIf somebody wants to see what the latest version of a blob looks\nlike while browsing the history with gitweb, I think it is a\nmore natural workflow to go to link and find the\nlatest version. So maybe you might want to add link in\nthe output of the history action?\n\n Side note: right now, link does not show any\n history newer than the commit that has the link itself;\n maybe there is a room for improvement there but we need\n to be careful not to trash the webserver caching.\n\nObviously you could go back to the repository top page and start\ndigging the latest tree from the top, but that is a bit more\ncumbersome.\n"}]}