Great, then your choices are (a) try and probably fail to get your changes upstreamed and/or (b) maintain your own fork of git forever.
This is very much a "if you don't like X about your country, just move to a different one" kind of "solution". The costs are extreme to the point that pretending it's viable is insulting. Really it's just a way to silence legitimate complaints.
to be fair, if you just want to improve the UX for yourself you can totally have a fork, make your changes, and use it on your own machines when talking to github or whatever other git repository. Now getting someone else to accept your changes might be harder, but that's what happens when you try to change a tool so many people use, especially one with a lot of history. Maintaining a fork is literally one of the things git was designed to make feasible after all.
Relying on porcelain commands' output is the official way of interacting with git, they famously always refused to break it into a library. Nobody is going to use the low level git commands because: 1. Their output isn't any more reliable than the porcelain, and 2. How the porcelain uses them is also subject to change, so your UI might end up doing something different from the git high level command which is undesirable.
At least they gave us the `--porcelain` flag, meant exactly for this use case, to make the output format of porcelain commands never change. Dumb flag name, though.
It's not really feasible to maintain private forks of every piece of software you use (especially something like git that needs regular security patches)
Great, then your choices are (a) try and probably fail to get your changes upstreamed and/or (b) maintain your own fork of git forever.
This is very much a "if you don't like X about your country, just move to a different one" kind of "solution". The costs are extreme to the point that pretending it's viable is insulting. Really it's just a way to silence legitimate complaints.
to be fair, if you just want to improve the UX for yourself you can totally have a fork, make your changes, and use it on your own machines when talking to github or whatever other git repository. Now getting someone else to accept your changes might be harder, but that's what happens when you try to change a tool so many people use, especially one with a lot of history. Maintaining a fork is literally one of the things git was designed to make feasible after all.
Probably unacceptable as many would have built tooling around the specific default behaviors.
If tooling is relying on the output format of porcelain commands, it's wrong. The output of various subcommands have already changed more than once.
Relying on porcelain commands' output is the official way of interacting with git, they famously always refused to break it into a library. Nobody is going to use the low level git commands because: 1. Their output isn't any more reliable than the porcelain, and 2. How the porcelain uses them is also subject to change, so your UI might end up doing something different from the git high level command which is undesirable.
At least they gave us the `--porcelain` flag, meant exactly for this use case, to make the output format of porcelain commands never change. Dumb flag name, though.
You can have your own version. You don’t have to push all improvements upstream.
It's not really feasible to maintain private forks of every piece of software you use (especially something like git that needs regular security patches)