All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: [PATCH] gitweb: reset input record separator in parse_commit even on error
Date: Sun, 10 Sep 2006 00:00:18 +0200	[thread overview]
Message-ID: <edvdgb$mtt$1@sea.gmane.org> (raw)
In-Reply-To: 20060909205159.GC16906@coredump.intra.peff.net

Jeff King wrote:

> On Sat, Sep 09, 2006 at 05:12:36PM +0200, Sven Verdoolaege wrote:
> 
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 7afdf33..60dd598 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -897,8 +897,8 @@ sub parse_commit {
>>              my $fd = git_pipe("rev-list", "--header", "--parents", "--max-count=1", $commit_id)
>>                      or return;
>>              @commit_lines = split '\n', <$fd>;
>> -            close $fd or return;
>>              $/ = "\n";
>> +            close $fd or return;
>>              pop @commit_lines;
>>      }
>>      my $header = shift @commit_lines;
> 
> You missed the other early return from git_pipe. However, I think the
> approach is wrong; this is a great opportunity to use the dynamic
> scoping offered by 'local':
> 
>   else {
>     local $/ = "\0";
>     # do stuff with $/ as "\0"
>   }
>   # $/ has automatically been reset at the end of the block

And this should be done consistently, for all plain formats 
(blob_plain, blobdiff_plain, commitdiff_plain), and some other
 places.

Sometimes it is
  local $/ = "\0";
more often
  local $/ = undef;
(or equivalently but slightly less human friendly, just 'local $/');

> Looking further at this bit of code, it seems even more confusing,
> though. We split the output of rev-list on NUL, grab presumably the
> entire thing (since there shouldn't be any NULs in the output, right?)
> and then split it on newline into a list. Why aren't we doing this:
>   else {
>     open my $fd, ...;
>     @commit_lines = map { chomp; $_ } <$fd>;
>     ...

That is because by default git-rev-list separates output for different
commits (when --header option is used) bu NULL... only because of 
"--max-count=1" there is only _one_ record... nevertheless it ends with 
"\0" (NULL) character.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

      reply	other threads:[~2006-09-09 22:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-09 15:12 [PATCH] gitweb: reset input record separator in parse_commit even on error Sven Verdoolaege
2006-09-09 20:51 ` Jeff King
2006-09-09 22:00   ` Jakub Narebski [this message]

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='edvdgb$mtt$1@sea.gmane.org' \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    /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.