git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Eli Barzilay <eli@barzilay.org>, git <git@vger.kernel.org>
Subject: Re: git-diff bug?
Date: Mon, 02 Nov 2020 14:00:18 -0800	[thread overview]
Message-ID: <xmqqpn4vs9l9.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <72cfef26-e986-d34c-eea4-46ec0fda2688@web.de> (=?utf-8?Q?=22R?= =?utf-8?Q?en=C3=A9?= Scharfe"'s message of "Mon, 2 Nov 2020 18:45:03 +0100")

René Scharfe <l.s.r@web.de> writes:

>     $ diff --ignore-blank-lines -u 1 2
>     --- 1	2020-11-02 18:11:04.618133008 +0100
>     +++ 2	2020-11-02 18:11:04.618133008 +0100
>     @@ -1,4 +1,4 @@
>      aaa
>      bbb
>     -ccc
>
>     +ccc
>     $ diff --ignore-blank-lines -u 2 1
>
> This matches your results.  That the order makes a difference is a bit
> odd.  Both are valid diffs of the inputs and neither one changes blank
> lines, though, so it doesn't look like a bug.

Interesting.  If "diff" happens to pick the line with "ccc" on it as
the unchanging pair of lines between the preimage and the postimage,
then another "valid diff of the inputs" would look like this:

     aaa
     bbb
    +
     ccc
    -

What such a patch would change consists only of blank lines.  It is
reasonable to expect "--ignore-blank-lines" would turn it into a
no-op, provided if "diff" picks "ccc" as the matching line.

But if "diff" picks that the blank line at the end of the original
file as unchanged line, then we'll see the diff quoted in the first
part of this message.  And that patch does not change any blank
lines, so it is unreasonable to expect "--ignore-blank-lines" to
turn it into a no-op.

So it all depends on which matching pair "diff" first picks, before
the "are all the lines changed by the hunk blank ones?" kicks in.

One could argue that "diff" should work hard to enumerate all the
possible combinations (we just saw two possible combinations above)
to find one that allows "--ignore-blank-lines" to produce an empty
patch, but I am not sure it is a sensible thing to do.


>     $ git diff --ignore-blank-lines 1 2
>     $ git diff --ignore-blank-lines 2 1
>     $ git --version
>     git version 2.29.2
>
> This matches your expectation, but not your results.  Which version do
> you use?
>
> René

      parent reply	other threads:[~2020-11-02 22:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02  6:53 Eli Barzilay
2020-11-02 17:45 ` René Scharfe
2020-11-02 21:06   ` Eli Barzilay
2020-11-02 22:14     ` Junio C Hamano
2020-11-03  3:14       ` Eli Barzilay
2020-11-03 16:58         ` Junio C Hamano
2020-11-02 22:00   ` Junio C Hamano [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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqpn4vs9l9.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=eli@barzilay.org \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --subject='Re: git-diff bug?' \
    /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

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).