Re: [PATCH 0/2] Support diff.wordDiff config
- From
- Dragan Simic <dsimic@manjaro.org>
- Date
- Mar 25, 2024, 21:53 UTC
- Message-ID
- <91f0848b917a15873a7b75b380619126@manjaro.org>
- In-Reply-To
- <6e035003-0c08-4e44-811c-27d2cebe9fa8@schinagl.nl>
On 2024-03-22 23:08, Olliver Schinagl wrote:
Show 36 quoted lines
> 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.