Hello, this new option looks quite reasonable to me.
Am Mo., 9. Feb. 2026 um 09:52 Uhr schrieb Florian Weimer <[email protected]>: > * Jan Engelhardt: > > > On Friday 2026-02-06 16:29, Florian Weimer wrote: > >>This new option can be used to prevent the application of patches in > >>commit messages that are part of git show output, for example. Such > >>text will be indented by for spaces. Without the --no-dedent option, > >>the patch tool incorrectly recognizes those diffs. > > > > Dedent? Not outdent (unindent, deindent, exdent)? > > > > It appears there is not one commonly widely accepted word for such an > > action linguistically, especially not in word processors where indent > > manipulation has been a staple since decades. > > I don't mind renaming the option. My choice would be --no-indent, telling patch not to recognize and remove indentation. In addition, the new option should probably disable RFC 934 encapsulation stripping as well. > > Maybe.. I'll be so bold as to propose making the effect of > > --no-dedent the default and instead have explicit > > --remove-indent/--remove-encapsulation (based on the description > > appearing in the patch.1 manpage). I can't remember the time I had to > > deal with an indented patch, and moreover, patch does not even > > handle the arguably most common indent, ">": > > I would not mind changing the default, either. That would break scripts that depend on the current behavior, so we cannot do that. > I can rework the patch in either direction, I just need a decision. 8-) I'd also appreciate if the tests could demonstrate the behavior with and without the new option. Thanks, Andreas
