From: "Michał Kiedrowicz" <michal.kiedrowicz@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/8] gitweb: Use print_diff_chunk() for both side-by-side and inline diffs
Date: Sun, 12 Feb 2012 00:16:24 +0100 [thread overview]
Message-ID: <20120212001624.4083c3b6@gmail.com> (raw)
In-Reply-To: <m3k43ttlh9.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
>
> > This renames print_sidebyside_diff_chunk() to print_diff_chunk() and
> > makes use of it for both side-by-side and inline diffs. Now diff lines
> > are always accumulated before they are printed. This opens the
> > possibility to preprocess diff output before it's printed.
> >
> > The new function print_inline_diff_lines() could reorder diff lines.
>
> I think you meant here "if left as is", isn't it?
Yes.
> > It first prints all context lines, then all removed lines and
> > finally all added lines. If the diff output consisted of mixed added
> > and removed lines, gitweb would reorder these lines. This is
> > especially true for combined diff output, for example:
> >
> > - removed line for first parent
> > + added line for first parent
> > -removed line for second parent
> > ++added line for both parents
> >
> > would be rendered as:
> >
> > - removed line for first parent
> > -removed line for second parent
> > + added line for first parent
> > ++added line for both parents
>
> This is not "is especially true"; it can happen (though: can it
> really?)
Yeah. See
http://git.kernel.org/?p=git/git.git;a=commitdiff;h=5de89d3abfca98b0dfd0280d28576940c913d60d
> in combined diff output; in ordinary diff you would always
> have context or end/beginning of chunk between added and removed
> lines.
OK, I'll reword this part of the commit message.
>
> >
> > To prevent gitweb from reordering lines, print_diff_chunk() calls
> > print_diff_lines() as soon as it detects that both added and removed
> > lines are present and there was a class change.
>
> You really should mention, in my opinion, that this change is
> preparation for diff refinement highlighting (higlighting the
> differing segments).
>
> Otherwise I don't see the reason for it: ordinary diff didn't need the
> fancy stuff with accumulating then printing, and could be send
> straightly to output. This adds complexity for non-sidebyside diff,
> unnecessary if not for diff refinement highlighting.
I completely agree with that. This patch doesn't makes sense without
later patches.
>
> > Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
> > ---
> > gitweb/gitweb.perl | 53 +++++++++++++++++++++++++++++++++++++--------------
> > 1 files changed, 38 insertions(+), 15 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 1247607..ed63261 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -4908,9 +4908,31 @@ sub print_sidebyside_diff_lines {
> > }
> > }
> >
> > -sub print_sidebyside_diff_chunk {
> > - my @chunk = @_;
> > +# Print context lines and then rem/add lines in inline manner.
> > +sub print_inline_diff_lines {
> > + my ($ctx, $rem, $add) = @_;
> > +
> > + print foreach (@$ctx);
> > + print foreach (@$rem);
> > + print foreach (@$add);
> > +}
> > +
> > +# Print context lines and then rem/add lines.
> > +sub print_diff_lines {
> > + my ($ctx, $rem, $add, $diff_style, $is_combined) = @_;
> > +
> > + if ($diff_style eq 'sidebyside' && !$is_combined) {
> > + print_sidebyside_diff_lines($ctx, $rem, $add);
> > + } else {
> > + # default 'inline' style and unknown styles
> > + print_inline_diff_lines($ctx, $rem, $add);
> > + }
> > +}
>
> That looks nice.
>
> BTW. I didn't examine the final code, but what happens for binary
> diffs that git supports? Is it handled outside print_diff_chunk()?
Good question. Will check.
>
> > +
> > +sub print_diff_chunk {
> > + my ($diff_style, $is_combined, @chunk) = @_;
> > my (@ctx, @rem, @add);
> > + my $prev_class = '';
>
> Is $prev_class here class of previous chunk fragment or _previous class_
> (i.e. always different from $class), or is it class of previous line?
> It is not obvious here, from variable name. Better name or at least
> a comment would be appreciated.
>
It's a class of previous line.
> >
> > return unless @chunk;
> >
> > @@ -4935,9 +4957,13 @@ sub print_sidebyside_diff_chunk {
> > }
> >
> > ## print from accumulator when have some add/rem lines or end
> > - # of chunk (flush context lines)
> > - if (((@rem || @add) && $class eq 'ctx') || !$class) {
> > - print_sidebyside_diff_lines(\@ctx, \@rem, \@add);
> > + # of chunk (flush context lines), or when have add and rem
> > + # lines and new block is reached (otherwise add/rem lines could
> > + # be reordered)
> > + if (((@rem || @add) && $class eq 'ctx') || !$class ||
> > + (@rem && @add && $class ne $prev_class)) {
>
> We usually use tabs to align, but spaces to indent in gitweb, so it
> would be
>
> > + if (((@rem || @add) && $class eq 'ctx') || !$class ||
> > + (@rem && @add && $class ne $prev_class)) {
>
OK.
> Anyway, this conditional gets ridicously complicated. I wonder if we
> could simplify it.
>
> If we allow printing context together widh added/removed lines, and
> not as soon as possible, perhaps good conditional would be: class
> changed, and accumulator for current class is full:
>
> > + if ($class ne $prev_class && @{ $acc{$class} }) {
>
> Or something like that, where
>
> my %acc = (ctx => \@ctx, add => \@add, rem => \@rem);
>
> If we want to print context as soon as possible, like it was before
> 1st patch in this series, we could uuse the following conditional
>
> > + if ($class ne $prev_class &&
> > + ($prev_class eq 'ctx' || @{ $acc{$class} })) {
>
> Perhaps with "scalar @{ $acc{$class} }" if it would make things more
> clear.
>
> Though probably to avoid "Use of uninitialized value in string ne"
> we would probably have to use empty string instead of undefined
> value for "no class" case, i.e. beginning or end of chunk.
>
OK, I'll try to work out something.
> > + print_diff_lines(\@ctx, \@rem, \@add, $diff_style,
> > + $is_combined);
> > @ctx = @rem = @add = ();
> > }
> >
> > @@ -4954,6 +4980,8 @@ sub print_sidebyside_diff_chunk {
> > if ($class eq 'ctx') {
> > push @ctx, $line;
> > }
> > +
> > + $prev_class = $class;
> > }
> > }
> [...]
>
next prev parent reply other threads:[~2012-02-11 23:16 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-10 9:18 [PATCH 0/8] gitweb: Highlight interesting parts of diff Michał Kiedrowicz
2012-02-10 9:18 ` [PATCH 1/8] gitweb: Extract print_sidebyside_diff_lines() Michał Kiedrowicz
2012-02-11 15:20 ` Jakub Narebski
2012-02-11 23:03 ` Michał Kiedrowicz
2012-02-10 9:18 ` [PATCH 2/8] gitweb: Use print_diff_chunk() for both side-by-side and inline diffs Michał Kiedrowicz
2012-02-11 15:53 ` Jakub Narebski
2012-02-11 23:16 ` Michał Kiedrowicz [this message]
2012-02-25 9:00 ` Michał Kiedrowicz
2012-02-10 9:18 ` [PATCH 3/8] gitweb: Move HTML-formatting diff line back to process_diff_line() Michał Kiedrowicz
2012-02-11 16:02 ` Jakub Narebski
2012-02-10 9:18 ` [PATCH 4/8] gitweb: Push formatting diff lines to print_diff_chunk() Michał Kiedrowicz
2012-02-11 16:29 ` Jakub Narebski
2012-02-11 23:20 ` Michał Kiedrowicz
2012-02-11 23:30 ` Michał Kiedrowicz
2012-02-10 9:18 ` [PATCH 5/8] gitweb: Format diff lines just before printing Michał Kiedrowicz
2012-02-11 17:14 ` Jakub Narebski
2012-02-11 23:38 ` Michał Kiedrowicz
2012-02-10 9:18 ` [PATCH 6/8] gitweb: Highlight interesting parts of diff Michał Kiedrowicz
2012-02-10 13:23 ` Jakub Narebski
2012-02-10 14:15 ` Michał Kiedrowicz
2012-02-10 14:55 ` Jakub Narebski
2012-02-10 17:33 ` Michał Kiedrowicz
2012-02-10 22:52 ` Splitting gitweb (was: Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff) Jakub Narebski
2012-02-10 20:24 ` [PATCH 6/8] gitweb: Highlight interesting parts of diff Jeff King
2012-02-14 6:54 ` Michal Kiedrowicz
2012-02-14 7:14 ` Junio C Hamano
2012-02-14 8:20 ` Jeff King
2012-02-10 20:20 ` Jeff King
2012-02-10 21:29 ` Michał Kiedrowicz
2012-02-10 21:32 ` Jeff King
2012-02-10 21:36 ` Michał Kiedrowicz
2012-02-10 21:47 ` [PATCH] diff-highlight: Work for multiline changes too Michał Kiedrowicz
2012-02-13 22:27 ` Jeff King
2012-02-13 22:28 ` [PATCH 1/5] diff-highlight: make perl strict and warnings fatal Jeff King
2012-02-13 22:32 ` [PATCH 2/5] diff-highlight: don't highlight whole lines Jeff King
2012-02-14 6:35 ` Michal Kiedrowicz
2012-02-13 22:33 ` [PATCH 3/5] diff-highlight: refactor to prepare for multi-line hunks Jeff King
2012-02-13 22:36 ` [PATCH 4/5] diff-highlight: match " Jeff King
2012-02-13 22:37 ` [PATCH 5/5] diff-highlight: document some non-optimal cases Jeff King
2012-02-14 6:48 ` Michal Kiedrowicz
2012-02-14 0:05 ` [PATCH] diff-highlight: Work for multiline changes too Junio C Hamano
2012-02-14 0:22 ` Jeff King
2012-02-14 1:19 ` Junio C Hamano
2012-02-14 6:04 ` Jeff King
2012-02-14 6:28 ` Michal Kiedrowicz
2012-02-10 21:56 ` [PATCH 6/8] gitweb: Highlight interesting parts of diff Jakub Narebski
2012-02-11 23:45 ` Jakub Narebski
2012-02-12 10:42 ` Jakub Narebski
2012-02-13 6:54 ` Michal Kiedrowicz
2012-02-13 19:58 ` Jakub Narebski
2012-02-13 21:10 ` Michał Kiedrowicz
2012-02-13 6:41 ` Michal Kiedrowicz
2012-02-13 18:44 ` Jakub Narebski
2012-02-13 21:09 ` Michał Kiedrowicz
2012-02-14 17:31 ` Jakub Narebski
2012-02-14 18:23 ` Michał Kiedrowicz
2012-02-14 18:52 ` Jeff King
2012-02-14 20:04 ` Michał Kiedrowicz
2012-02-14 20:38 ` Jeff King
2012-02-10 9:18 ` [PATCH 7/8] gitweb: Use different colors to present marked changes Michał Kiedrowicz
2012-02-12 0:11 ` Jakub Narebski
2012-02-13 6:46 ` Michal Kiedrowicz
2012-02-10 9:18 ` [PATCH 8/8] gitweb: Highlight combined diffs Michał Kiedrowicz
2012-02-12 0:03 ` Jakub Narebski
2012-02-13 6:48 ` Michal Kiedrowicz
2012-02-11 18:32 ` [PATCH 0/8] gitweb: Highlight interesting parts of diff Jakub Narebski
2012-02-11 22:56 ` Michał Kiedrowicz
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=20120212001624.4083c3b6@gmail.com \
--to=michal.kiedrowicz@gmail.com \
--cc=git@vger.kernel.org \
--cc=jnareb@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).