From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Kato Kazuyoshi <kato.kazuyoshi@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH/RFC 1/2] gitweb: change format_diff_line() to remove leading SP from $diff_class
Date: Tue, 18 Oct 2011 00:07:30 +0200 [thread overview]
Message-ID: <201110180007.31008.jnareb@gmail.com> (raw)
In-Reply-To: <7v62jnl3ef.fsf@alter.siamese.dyndns.org>
On Mon, 17 Oct 2011, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> By the way, it is common to either have following patches to be chain
>> reply to first patch, or better provide cover letter for patch series
>> and have all patches be reply to cover letter.
>
> It may be a good discipline for 14 patch series, but it doesn't matter for
> something this small.
Well, cover letter for 2-patch series might be overkill, but having
patches in series connected e.g. chain-replied-to, or all replies to
first patch in series, is IMHO a good idea.
>>> gitweb/gitweb.perl | 24 +++++++++++++-----------
>>> 1 files changed, 13 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>>> index 85d64b2..095adda 100755
>>> --- a/gitweb/gitweb.perl
>>> +++ b/gitweb/gitweb.perl
>>> @@ -2235,28 +2235,30 @@ sub format_diff_line {
>>> # combined diff
>>> my $prefix = substr($line, 0, scalar @{$from->{'href'}});
>>> if ($line =~ m/^\@{3}/) {
>>> - $diff_class = " chunk_header";
>>> + $diff_class = "chunk_header";
>>> } elsif ($line =~ m/^\\/) {
>>> - $diff_class = " incomplete";
>>> + $diff_class = "incomplete";
>>> } elsif ($prefix =~ tr/+/+/) {
>>> - $diff_class = " add";
>>> + $diff_class = "add";
>>> } elsif ($prefix =~ tr/-/-/) {
>>> - $diff_class = " rem";
>>> + $diff_class = "rem";
>>> }
>>
>> Hmmm... that reminds me: this if-elsif chain is a bit ugly, but would
>> be hard to replace without given ... when, I think.
>
> I wasn't reading the existing context line, but now that you mention it,
> they are not just ugly but are borderline of being incorrect (e.g. it does
> not catch a broken hunk-header that begins with "@@@@" for a two-way
> merge).
>
> Assuming that $from->{'href'} has all the parents (i.e. 2 for two-way
> merge), shouldn't the code be more like this?
>
> # combined diff
Wouldn't that cover not only combined diff, but an "ordinary" diff as
well then (i.e. comment should change)? I think that was the intent,
isn't it?
> my $num_sign = @{$from->{'href'}} + 1;
$from->{'href'} is array reference only for combined diff (>= 2 parents).
For ordinary diff it is a scalar.
> my @cc_classifier = (
> ["\@{$num_sign} ", "chunk_header"],
O.K.
Nb., it is "chunk_header", or "hunk_header"?
> ['\\', "incomplete"],
O.K.
> [" {$num_sign}", ""],
O.K.
> ["[+ ]{$num_sign}", "add"],
> ["[- ]{$num_sign}", "rem"],
It would be slightly different to what current code does.
Current code for combined diff uses "add" if there is at least one '+',
"rem" if there are no '+' and at least one '-', and context otherwise.
I wonder if with sufficiently evil merge we can have a line that is
added (changed) in some children, and removed in other, i.e. pluses
and minuses combined.
Nb. we can put regexp here, not only stringification of regexp.
i.e.
[qr/[+ ]{$num_sign}/, "add"],
[qr/[- ]{$num_sign}/, "rem"],
> );
> for my $cls (@cc_classifier) {
> if ($line =~ /^$cls->[0]$/) {
> $diff_class = $cls->[1];
> last;
> }
> }
Nice trick.
> Also don't we want to use "context" or something for the css class for the
> context lines, instead of assuming that we won't want to paint it in any
> special color?
Right. We use "diff" class without anything else for context, but probably
it would be better to state this explicitly.
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2011-10-17 22:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 6:59 [PATCH/RFC 1/2] gitweb: change format_diff_line() to remove leading SP from $diff_class Kato Kazuyoshi
2011-10-17 19:02 ` Junio C Hamano
2011-10-17 23:58 ` Kato Kazuyoshi
2011-10-17 20:56 ` Jakub Narebski
2011-10-17 21:22 ` Junio C Hamano
2011-10-17 22:07 ` Jakub Narebski [this message]
2011-10-17 23:20 ` Junio C Hamano
2011-10-18 18:26 ` [PATCH] gitweb: Refactor diff body line classification Jakub Narebski
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=201110180007.31008.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kato.kazuyoshi@gmail.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).