Re: [Bug report] diff.noprefix config is ignored for interactive `add`

[Jeff King <peff@peff.net>]

On Tue, Apr 06, 2021 at 02:57:46PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > I imagine something like this:
> > ...
> > would work, but I didn't really test it. There's another hitch, which is
> > that this subsystem has all been re-written in C. So we'd really want to
> > implement it in the new code (possibly in both places, though maybe it
> > is time to consider cutting over from the perl script to the C one by
> > deafult?).
> >
> > But hopefully this illustrates the general idea, and gives somebody
> > interested in the feature enough to work up their own patch.
> 
> These "cosmetic appearance" configuration that would affect the
> output from diff shown to the user would not be limited to just the
> .noprefix, though.  Depending on the users, they would care just as
> deeply about any of these:
> 
> 	.context
> 	.interHunkContext
> 	.mnemonicPrefix
>         .noprefix
> 	.relative
> 	.orderFile
> 
> as Nikita does for .noprefix to send a bug report.
> 
> Luckily or unluckily, .suppressBlankEmpty and the per-filetype
> .xfuncname patterns do impact the output from the plumbing, because
> git_diff_basic_config() does read them, even though they are merely
> "cosmetic" configurations.
> 
> I am unsure how much we should cater to end-user controlled
> configuration when we are generating diff output for our own
> consumption, but if we were to tweak "add -p" and friends to
> pay attention to .noprefix, we probably should do the same for
> all the others.

Yes. We already have gone through this with other options (e.g.,
diff.algorithm). I would be happy if somebody wanted to handle the
complete set. But I am also OK with stumbling towards completeness, as
people who care about a particular option plumb it through.

-Peff