On 2024-03-22 23:08, Olliver Schinagl wrote:
On 03-03-2024 18:45, Junio C Hamano wrote:
Chris Torek <chris.torek@xxxxxxxxx> 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.
