3 ms·

I think we can all agree that information should be behind a -v CLA. It's probably just something no one has thought of doing. I've learned over the decades t

by e40 4mo ago

I think we can all agree that information should be behind a -v CLA. It's probably just something no one has thought of doing. I've learned over the decades to just ignore it.

maccard 4mo ago
> 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.
- yoyohello13 4mo ago
  Luckily it’s an open source project so you could go in and clean up the ux.
  - LtdJorge 4mo ago
    Probably unacceptable as many would have built tooling around the specific default behaviors.
    - Jaxan 4mo ago
      You can have your own version. You don’t have to push all improvements upstream.
      - swiftcoder 4mo ago
        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)
    - throw_await 4mo ago
      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.
      - tredre3 4mo ago
        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.
  - andrewflnr 4mo ago
    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.
    - deleted 4mo ago
      [deleted]
    - MobiusHorizons 4mo ago
      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.
      - pseudalopex 4mo ago
        https://news.ycombinator.com/item?id=48573493 https://news.ycombinator.com/item?id=48573493
foresto 4mo ago
> 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.
- throw_await 4mo ago
  That makes me sad. This termainology is really one of the major flaws of git, along with the checkout/reset thing
  - js2 4mo ago
    https://news.ycombinator.com/item?id=48574124 https://news.ycombinator.com/item?id=48574124
- js2 4mo ago
  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=commits 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/ 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+documentation&type=commits https://github.com/search?q=repo%3Agit%2Fgit+jaysoffian+docu... Generically: https://github.com/search?q=repo%3Agit%2Fgit+documentation&type=commits https://github.com/search?q=repo%3Agit%2Fgit+documentation&t... Do you have a link to your proposal on the git mailing list?
- Melatonic 4mo ago
  Are those three really all the same things? That seems crazy to have all three not consolidated.
  - 4mo ago
1718627440 4mo ago
I do want a progress indicator for something that might take a while without asking. If you clone things locally, Git only reports that it cloned something.

by e40 4mo ago

I think we can all agree that information should be behind a -v CLA. It's probably just something no one has thought of doing. I've learned over the decades to just ignore it.

maccard 4mo ago

> 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.

yoyohello13 4mo ago
Luckily it’s an open source project so you could go in and clean up the ux.
- LtdJorge 4mo ago
  Probably unacceptable as many would have built tooling around the specific default behaviors.
  - Jaxan 4mo ago
    You can have your own version. You don’t have to push all improvements upstream.
    - swiftcoder 4mo ago
      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)
  - throw_await 4mo ago
    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.
    - tredre3 4mo ago
      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.
- andrewflnr 4mo ago
  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.
  - deleted 4mo ago
    [deleted]
  - MobiusHorizons 4mo ago
    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.
    - pseudalopex 4mo ago
      https://news.ycombinator.com/item?id=48573493 https://news.ycombinator.com/item?id=48573493

foresto 4mo ago

> 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.

throw_await 4mo ago
That makes me sad. This termainology is really one of the major flaws of git, along with the checkout/reset thing
- js2 4mo ago
  https://news.ycombinator.com/item?id=48574124 https://news.ycombinator.com/item?id=48574124
js2 4mo ago
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=commits 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/ 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+documentation&type=commits https://github.com/search?q=repo%3Agit%2Fgit+jaysoffian+docu... Generically: https://github.com/search?q=repo%3Agit%2Fgit+documentation&type=commits https://github.com/search?q=repo%3Agit%2Fgit+documentation&t... Do you have a link to your proposal on the git mailing list?
Melatonic 4mo ago
Are those three really all the same things? That seems crazy to have all three not consolidated.
- 4mo ago

1718627440 4mo ago

I do want a progress indicator for something that might take a while without asking. If you clone things locally, Git only reports that it cloned something.