From: Dragan Simic Date: Mon, 25 Mar 2024 21:53:55 GMT Subject: Re: [PATCH 0/2] Support diff.wordDiff config Message-ID: <91f0848b917a15873a7b75b380619126@manjaro.org> In-Reply-To: <6e035003-0c08-4e44-811c-27d2cebe9fa8@schinagl.nl> On 2024-03-22 23:08, Olliver Schinagl wrote: > On 03-03-2024 18:45, Junio C Hamano wrote: >> Chris Torek 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.