https://news.ycombinator.com/item?id=48574124

Cache is like the old name, index is the new name, because the implementation didn't really make sense to use as a term for the users. Staging area was invented by third-parties as a term for training. Now Git uses --cached to mean only work on the context cached in the index and --index to mean also look at the --index. --stages exists as an alias for --cached for the people who want it, but it has no additional meaning and is not advertised in the documentation.

The actual documentation is actually sensible, the issue is just that most people just learn from third parties, who are lax with terms.

> At the end user level, "cache" is only used as an adjective these days; "cached", meaning "contents cached in the index, not the contents in the work tree". We could have called it "indexed", but "cached contents" was an already established phrase from very early days to mean that exact concept, and we did not need another word that meant the same thing.

> There are some commands that take --index and --cached options, and even some that can take both (but not at the same time). Many people find this confusing, but there is a pair of simple rules:

    "--cached" always means "work only on contents cached in the index, ignoring the work tree";
    "--index" makes a command that usually works on files in the work tree also pay attention to the index.

    "git apply" usually patches the files in the work tree without touching the index.
    "git apply --cached" only updates the contents in the index without modifying the file in the work tree.
    "git apply --index" patches both the contents in the work tree and in the index.
    "git diff HEAD" shows a patch to update the contents in the HEAD commit to contents in the work tree.
    "git diff --cached HEAD" shows a patch to update the contents in the HEAD commit to contents that is cached in the index.  "git diff --cached" is a short-hand for "git diff --cached HEAD" only because the HEAD commit is what you most often would want to compare the cached contents with.
    There is no "git diff --index HEAD" (yet); it would imply showing a three-way diff between HEAD, the index and the work tree.
    "git grep" finds matches in the work tree.
    "git grep --cached" finds matches in the contents in the index.
    "git rm" removes both the file in the work tree and the corresponding path in the index.
    "git rm --cached" removes the path from the index, leaving the file in the work tree untracked.

Yes.

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.

Probably unacceptable as many would have built tooling around the specific default behaviors.

And yet, even for programmers, that output is full of info that is useless 99.9% of the time. That is just bad design. It is basically a debug log that is shown by default all the time, instead of written to a log somewhere for the <0.1% time it's useful.

And I point out the attitude because I've seen it for decades and seen the harm this kind of "it's just harmless extra info" type thinking has brought. I don't know what tone you're reading into it, but I'm quite literally and explicitly criticizing the attitude, not you personally.

I'm a programmer and I understand Git internals decently well, but unless something went wrong, I pay zero attention to the verbose output of `git push`. BTW, isn't "avoid unnecessary output" one of the Unix philosophies?

> FFS, git is a tool for programmers.

We already said it has a garbage UI, you don't need to repeat it

But jokes aside, usually the reason something is considered a "tool for programmers" and not just a tool is because the UI sucks.

I feel like you’re either misunderstanding the entire thread or being obtuse on purpose.

The point is that “Delta compression using up to 10 threads” means nothing to most users - it’s also not a progress thing. Hide it unless the user does -v or something.

How often do you really need to look at that info while doing normal work?

Because to me and to the very vast majority of git users it is totally irrelevant.

It is nice that the info is available, but the more sane default would be to hide under a verbose flag not the other way around.

Imagine typing cd folder/ and have the whole filesystem subtree be displayed in the terminal. You are free to ignore it, but it is useless and inconvenient nonetheless

I apologize if I came off harsh and combative. Gamedev is a passion for me and I spent many years in that field, including working on proprietary version control systems because existing ones like SVN, Git, Perforce...etc did not fit the needs of the team.

One of the things I very frequently heard from the non-programmer disciplines was how obtuse and indecipherable the existing version control systems were. That is where I'm coming from.

Your knowledge is still appreciated, by me as well, because while I am well familiar with the way git works, I have worked with many people who were not, and did not have the time or budget in their minds for understanding it because they had many other concerns. That is what I mean when I said that I worked with some brilliant people -- I could not do even a modicum of what some of them were capable, and likewise they probably weren't capable of the same modicum of what I was doing.

I don't know what specifically the GP post was trying to insinuate, if anything at all, but it resonated with me as someone who had experienced the same thing many times over in my career. And I probably judged your comment a little harshly on first read, which is mea culpa. You provided good information for those newer to git and seeking to understand how it actually works besides the cheat sheet guides you so often find.

> Git is a tool by programmers for programmers. If folks outside the programming community are able to use it, great, but that's not its target audience. You don't need to convince me why git isn't suitable for artists.

Precisely, and I think Lore is an interesting proposition for exactly that reason.

While I agree that git is a tool for the development of an operating system kernel, it's become clear that this is not the general perception of it. I don't mean those of us who have followed it throughout it's evolution, but those that are not 'in the know'. I have heard probably too many programmers pushing it as the end-all-be-all solution for version control even in environments not appropriate for it.

I will disagree that the output is too complex; it is. And yes, the large binaries issue is also a huge challenge to it's use. There's only so much time in the day, and when you work in gamedev there are often severe pressures to perform, and spending extra time to get into the weeds of a version control system is often not possible without sacrifice.

No, it's mostly nonsense to them.

You know what's a progress indicator? An actual progress indicator. Not some text telling you such and such process is 1234/5678 steps done...followed by yet another line of text telling you that the process is now at step 3 of 20. It could just be a % indicator with a spinning cursor, unless the -v/-verbose flag is present.

Of course artists can learn to understand what all this means; But that is not their job, they have other things to deal with besides the esoteric and overly verbose CLIs we programmers often make.

Yes, then it breaks because you gave your artist an SSH link to clone and LFS requires a HTTPS auth token and exits with terse errors.

Or, you need to lock your files and git doesn't really support that.

To be fair, your hypothetical is true: UE5 supports Git as a backend, you don't need to run git commands (most of the time), but in practice even in the best circumstances: Git for game dev is brittle, slow, and extremely space inefficient.

Worse still: people try pushing their "short lived branches" workflow when using Git, which is *not* how gamedev works, especially for artists. Longer lived changesets are more common. (in Perforce these are called Shelves).

> artist should use any of the nice frontends that work on top of git and hide its verbosity.

Right up until something goes fucky. You know how many times I got messaged by someone dealing with vcs going wrong for them at a late hour in the evening? If I had a nickel for every time, I wouldn't be rich, but it probably would have bought me a gallon of gas.

It's not the verbosity strictly speaking. It is the minimal level of abstraction between you and the vcs and it can hardly be helped by a 'nice frontend' when things go wrong. And they will; they always do.

and why don't we just follow decades of conventions and add a --verbose/-v flag to display all the gobbledegook if you really want to, but hide it by default? As far as I remember, the guidance has always been "only print something if the user needs to know, no output means success."

git would be perfectly usable without knowing how many objects it has pushed or how fast it was doing so.

You mean `jj advance bookmarks`? It still seems like a pain to not just have it happen automatically on `commit`. (I use the "experimental" auto-advance-bookmarks feature, but it's got a lot of papercuts.)

afaik they're randomly generated so you're likely the first and last person to see that permutation

> The point was that this bothered me when I used git for the very first time

and that is fine. From your original comment, you "just" wanted to save things and got confused why you had to `add`, `commit` and `push`. Its just that you didn't know that git isn't a word processor that gives you a way to save your work - you've done that already when you saved the file with your editor.

When I came to git, I was also confused why commit and push are different steps - so much work, I thought. Until one day it finally hit - wait, this lets me keep "saving" my work locally until I'm ready to upload it - which is when I push.

You can also just do `git commit -a` to commit all modified files.

> I feel like other commenters are being obtuse on purpose and avoid the point?

nah, people are just built differently. Not everyone gets frustrated with "learning to remember", and then some do. Both are valid. The people who seem to be obtuse to you are in the first group, myself included. I didn't instantly catch the fact that instead of `svn commit` I have to now do `git add`, `git commit` and `git push`. But, and this is the key difference, when I forgot I just checked my bash history to recall the sequence. It doesn't bother me because I know either of two things will happen:

A. Over months and years, you then understand how things work and its second nature.

OR B. The tool was just a one-off and you won't use it after some time, so it doesn't matter you won't recall the steps.

Its the same with any professional tool, really - even outside software (think carpentry, for example).

Reading the docs is kind of a superpower for devs. With AI I think most technology is going to be treated like praying to the machine spirit.

If you don't read the documentation you can't complain if a machine stays a mystery for you. Normally you don't get to use a machine without proving you actually now what you are doing.