upvote

points

by e404 hours ago |
comments
upvoteby foresto2 hours ago|
next
[-]
> It's probably just something no one has thought of doing.

One might reasonably think that about a number of git's rough edges, and one might be surprised at the reality.

Some years ago, the annoyance of git's inconsistent terminology drove me to look into consolidating "cache", "index", and "staging area" in git's help text and documentation. What I found was that others had (of course) thought of it before, but when they tried to do it, it was rejected by git's gatekeepers.

reply
upvoteby throw_await1 hours ago|
parent|
next
[-]
That makes me sad. This termainology is really one of the major flaws of git, along with the checkout/reset thing
reply
upvoteby Melatonic30 minutes ago|
parent|
prev|
next
[-]
Are those three really all the same things? That seems crazy to have all three not consolidated.
reply
upvoteby js21 hours ago|
parent|
prev|
[-]
I understand there's friction in contributing to git, but it's absolutely possible to improve the docs:

Contributions from jvns:

https://github.com/search?q=repo%3Agit%2Fgit+jvns&type=commi...

Here she explains how she did it:

https://jvns.ca/blog/2026/01/08/a-data-model-for-git/

Contributions I've made:

https://github.com/search?q=repo%3Agit%2Fgit+jaysoffian+docu...

Generically:

https://github.com/search?q=repo%3Agit%2Fgit+documentation&t...

Do you have a link to your proposal on the git mailing list?

reply
upvoteby maccard3 hours ago|
prev|
[-]
> It's probably just something no one has thought of doing

There are 1000 things that's true of about git. At a certain point that becomes a problem in and of itself.

reply
upvoteby yoyohello133 hours ago|
parent|
[-]
Luckily it’s an open source project so you could go in and clean up the ux.
reply
upvoteby andrewflnr1 hours ago|
parent|
next
[-]
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.

reply
upvoteby 57 minutes ago|
parent|
[-]
deleted
reply
upvoteby LtdJorge3 hours ago|
parent|
prev|
[-]
Probably unacceptable as many would have built tooling around the specific default behaviors.
reply
upvoteby throw_await1 hours ago|
parent|
next
[-]
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.
reply
upvoteby tredre33 minutes ago|
parent|
[-]
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.

reply
upvoteby Jaxan2 hours ago|
parent|
prev|
[-]
You can have your own version. You don’t have to push all improvements upstream.
reply
upvoteby swiftcoder2 hours ago|
parent|
[-]
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)
reply