Re: [PATCH 0/2] Support diff.wordDiff config

[Dragan Simic <dsimic@manjaro.org>]

On 2024-03-22 23:08, Olliver Schinagl wrote:
> On 03-03-2024 18:45, Junio C Hamano wrote:
>> Chris Torek <chris.torek@gmail.com> writes:
>> 
>>> This tension is relieved somewhat when there *are* separate
>>> plumbing commands, such as `git diff-index` and `git diff-tree`
>>> and so on, or `git rev-list` vs `git log`. Unfortunately there
>>> are some commands, including `git log` itself, that have options
>>> that are missing from the roughly-equivalent plumbing command,
>>> and there are commands (such as `git stash` and `git status`)
>>> that either do not have, or at one time lacked, plumbing command
>>> equivalents or options.
>> 
>> Yup.  It is my pet peeve that more and more contributors got lazy
>> and tweaked only Porcelain commands, without bothering to improve
>> plumbing commands to match, while adding more features during the
>> last decade.  Unfortunately there is no easy remedy after such sins
>> have been committed.  Once people start using `git log` in their
>> scripts, it is way too late to tell them to update their scripts to
>> use `git log --porcelain`.  The fact that you need to tell them is
>> an admission that you already broke their scripts.
>> 
> To avoid this request from dieing quietly, I will ask (complain)
> again. Who's the client for. How important is the human UX?
> 
> Even introducing a new cli, 'git-cli-for-humans' it will be abused
> again for sure. So what's a good way forward? Personally, as I
> mentioned before, it's in the docs to not script around non-plumbing
> commands, which gives an opening to the admission. And why is
> admitting things a bad thing, when it improves things for the human?
> Even if it hurts.
> 
> One could argue 'git3 will break things! Human and machine control is
> split. Use --porcelain (or plumbing commands) in your scripts or
> expect breakage from time to time. You have been warned!'
> 
> We do in the end want progress, do we not? :)

Maybe, but just maybe, a possible solution for introducing such new
configuration options could be introduce a new category of configuration
options, which could be set in the user's git configuration only?

That way, a repository enabling some troublesome configuration option
wouldn't cause the user's scripts to break.