git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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