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

From: Olliver Schinagl <oliver@schinagl.nl>
Date: Mar 22, 2024, 22:05 UTC
Message-ID: <0c8f5b5b-ed25-483e-901c-cd0850640697@schinagl.nl>
In-Reply-To: <CAPx1GveaNR9ooWqE1VkAuFg5NO4Lwzx7bj-W1mWeHRg-rcg6+w@mail.gmail.com>

On 03-03-2024 08:23, Chris Torek wrote:

Show 24 quoted lines

> Continuing the digression a bit:
> 
> On Sat, Mar 2, 2024 at 11:58 AM Kristoffer Haugsbakk
> <code@khaugsbakk.name> wrote:
>> This looks similar to the discussion from a [stash] topic:
>>
>> • Proposed introducing config variables which change how `git stash
>>    push` and `git stash save` behave (what they save)
>> • Concern about how that could break third-party scripts
> [snippage]
>> 🔗 [stash]: https://lore.kernel.org/git/xmqq34tnyhhf.fsf@gitster.g/
> 
> As I see it, the general issue here is the tension between Git
> commands that are used for scripting -- which ideally should
> always be plumbing commands -- and those used by end-users.
> 
> 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.

I think you are spot on; and as I mentioned earlier, who is git for? Which commands are for whom. Human or machine. I suppose you can never avoid commands being abused, but should we favor machine abuse for very poor UX for the human? I would say 'absolutly not' but up until now, this has always been the case.

Maybe it comes from Linus's strict 'never break userspace'. But I think the situation is different. We want to enrich the user experience, we are constantly degrading it in favor of machines. Even though the manuals and interwebs are full of 'don't use these commands in scripts, they may break'. In that light, I would say 'lets break it in favor of UX :p

> 
> The `git status` command shows one way out of this problem:
> we can *add* `--porcelain` options.  Perhaps every command (or
> every non-plumbing-only one) should have `--porcelain[=<version>]`.

That's a fair argument, and makes it clear, however, there's tons of scripts that probably don't do this right now.

Show 5 quoted lines

> 
> This doesn't fix the situation today, but provides an obvious
> future-proofing path.
> 
> Chris