All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com>,
	git@vger.kernel.org, "Holger Weiß" <holger@zedat.fu-berlin.de>
Subject: Re: [PATCH/RESEND] gitweb: Fix snapshots requested via PATH_INFO
Date: Mon, 20 Apr 2009 02:52:48 -0700 (PDT)	[thread overview]
Message-ID: <m3iqkzps96.fsf@localhost.localdomain> (raw)
In-Reply-To: <200904151934.10253.jnareb@gmail.com>

I'm sorry for resend, but I forgot to quote non-ASCII in 'Cc:'
and vger anti-SPAM filter rejected message...

Jakub Narebski <jnareb@gmail.com> writes:
> On Wed, 15 April 2009, Junio C Hamano wrote:
>> Holger Weiß <holger@zedat.fu-berlin.de> writes:
>> 
>>> Fix the detection of the requested snapshot format, which failed for
>>> PATH_INFO URLs since the references to the hashes which describe the
>>> supported snapshot formats weren't dereferenced appropriately.
>>>
>>> Signed-off-by: Holger Weiß <holger@zedat.fu-berlin.de>
>>> ---
>>> I guess this one got lost.  Without this patch, snapshots won't work if
>>> Gitweb is configured to generate PATH_INFO URLs.  (Original Message-ID:
>>> <20090331161636.GV30233737@CIS.FU-Berlin.DE>).
>> 
>> The patch looks obviously correct; "our %known_snapshort_formats" maps a
>> name to a hashref, but the current code makes a nonsense assignment,
>> essentialy doing ($fmt, %opt) = ($name, $hashref), but what would I
>> know...  I am not using gitweb actively.
>> 
>> These lines come from 1ec2fb5 (gitweb: retrieve snapshot format from
>> PATH_INFO, 2008-11-02) by Guiseppe.
>> 
>> Judging from the "git shortlog -n -s --grep=PATH_INFO gitweb" output, I
>> think I should have heard from either Guiseppe and Jakub by now if this
>> patch is desired.  Pinging them...
> 
> This change looks correct, and is very much desired.  Thanks for
> catching this.

Ping!  This is quite straighforward bugfix for a new feature...

> By the way, if there was check added for full path_info snapshot URL in
> existing t/t9500-gitweb-standalone-no-errors.sh it would caught this
> bug thanks to the
>   "Odd number of elements in hash assignment ..."
> warning that Perl throws in this case. 

... or are you waiting for test case?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

  reply	other threads:[~2009-04-20  9:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090414104648.GA36554444@CIS.FU-Berlin.DE>
2009-04-15  6:40 ` [PATCH/RESEND] gitweb: Fix snapshots requested via PATH_INFO Junio C Hamano
2009-04-15  9:33   ` Giuseppe Bilotta
2009-04-15 10:09     ` Holger Weiß
2009-04-15 11:29       ` Giuseppe Bilotta
2009-04-15 17:34   ` Jakub Narebski
2009-04-20  9:52     ` Jakub Narebski [this message]
2009-04-20 10:41       ` Junio C Hamano

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=m3iqkzps96.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=giuseppe.bilotta@gmail.com \
    --cc=holger@zedat.fu-berlin.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.