From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Ilya Tumaykin <itumaykin@gmail.com>,
git@vger.kernel.org, Jeff King <peff@peff.net>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: git crashes in `git commit --patch` with diff.suppressBlankEmpty = true
Date: Fri, 05 Jul 2024 09:39:52 -0700 [thread overview]
Message-ID: <xmqq4j937pyf.fsf@gitster.g> (raw)
In-Reply-To: <ab974e62-098c-4200-bee3-7de8d9115516@gmail.com> (Phillip Wood's message of "Thu, 4 Jul 2024 14:14:56 +0100")
Phillip Wood <phillip.wood123@gmail.com> writes:
> ... but I wonder if we
> should change 'diff-index' and 'diff-files' to ignore
> diff.suppressBlankEmpty instead. The plumbing diff commands already
> ignore most of the options that change diff output so I'm not quite
> sure why they respect this particular config setting.
Very true. Even though POSIX adopted the text:
It is implementation-defined whether an empty unaffected line is
written as an empty line or a line containing a single <space>
character.
it merely allows the implementation to show an empty unaffected line
as an empty line (where traditionally such an output was not allowed),
and we probably want to give priority to consistent and stable output.
If the addition of diff.suppressBlankEmpty were done in the usually
recommended way to first add command line option to prove that the
feature is useful and then add configuration variable to pretend as
if it were passed, then it would have been perfect. We then could
have made the plumbing to completely ignore the configuration to
make the output more stable, while allowing script writers a choice
to invoke plumbing commands with explicit comand line options.
But that was not what happened, unfortunately.
If we really wanted to force the world line to where we did what we
should have done back then, I would say we need to do a two-step
transition.
- Add the --[no-]suppress-blank-empty option from the command line
to all commands in the diff family. Plumbing diff trio will
still pay attention to diff.suppressBlankEmpty but when they see
it is set to any non-default value (i.e. true) without being set
by the new command line option, we loudly warn that we will fix
this historical mistake in Git 3.0 and encourage script writers
to update their invocation of plumbing diff trio to use the
command line to custimze.
- At Git 3.0, plumbing diff trio stops paying attention to the
diff.suppressBlankEmpty configuration. By this time, the warning
we gave in earlier versions would have helped existing scripts to
migrate away from relying on it and if they want they would
instead explicitly pass the command line option, so we stop
warning.
As to the "commit -p" issue, I think the patch parser is in the
wrong and needs to be corrected, period. As long as the patches
given as input are well-formed, we should be prepared to grok
them (we even allow manual editing of patches, right?).
Thanks.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/diff.html
next prev parent reply other threads:[~2024-07-05 16:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 14:41 git crashes in `git commit --patch` with diff.suppressBlankEmpty = true Ilya Tumaykin
2024-07-04 13:14 ` Phillip Wood
2024-07-05 16:39 ` Junio C Hamano [this message]
2024-07-10 9:36 ` [RFC/PATCH] add-patch: handle splitting hunks with diff.suppressBlankEmpty Jeff King
2024-07-10 13:46 ` Phillip Wood
2024-07-11 21:26 ` Jeff King
2024-07-13 13:19 ` phillip.wood123
2024-07-13 21:21 ` Jeff King
2024-07-18 14:22 ` Phillip Wood
2024-07-18 14:23 ` Phillip Wood
2024-07-10 17:06 ` Junio C Hamano
2024-07-11 21:32 ` Jeff King
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=xmqq4j937pyf.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=itumaykin@gmail.com \
--cc=johannes.schindelin@gmx.de \
--cc=peff@peff.net \
--cc=phillip.wood123@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).