git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git crashes in `git commit --patch` with diff.suppressBlankEmpty = true

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 5, 2024, 16:39 UTC
Message-ID
<xmqq4j937pyf.fsf@gitster.g>
In-Reply-To
<ab974e62-098c-4200-bee3-7de8d9115516@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
Show 5 quoted lines
> ... 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
Previous: Phillip WoodNext: Jeff King
Message 3 of 12 in “git crashes in `git commit --patch` with diff.suppressBlankEmpty = true”
  1. Ilya TumaykinJul 3, 2024
  2. Phillip WoodJul 4, 2024
  3. Junio C HamanoJul 5, 2024
  4. add-patch: handle splitting hunks with diff.suppressBlankEmptyJeff King, Jul 10, 2024
  5. Phillip WoodJul 10, 2024
  6. Jeff KingJul 11, 2024
  7. phillip.wood123@gmail.comJul 13, 2024
  8. Jeff KingJul 13, 2024
  9. Phillip WoodJul 18, 2024
  10. Phillip WoodJul 18, 2024
  11. Junio C HamanoJul 10, 2024
  12. Jeff KingJul 11, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.