3 ms·

To be honest, I think this behavior is quite useful. Staging just means "I'm happy with the changes so far but didn't finish everything I want in my commit; le

To be honest, I think this behavior is quite useful. Staging just means "I'm happy with the changes so far but didn't finish everything I want in my commit; let's ignore this changes for now". What `git diff` does by default becomes useful when you touch the staged changes again. Then you see only the new changes compared to the staged stuff. This helps building up a commit step by step, with some trail and error in between. Think for example about something like: You use some tool to do some automatic changes. This creates hundreds of changed files. But the result isn't working. You could commit that, sure. But than you would need to rewrite history before pushing because creating not working commits is a terrible idea. Or you could just stage the changes for now. Than you can change / repair the still missing parts. Git diff will helpfully show you only the new changes but ignore the staged stuff as long as it's untouched. You would now for example easily see changes that you made to the automatic rewrites. Without the staging behavior you could only compare with a committed state, and drown in hundreds of changes that are unrelated. The main problem with the staging area is that quite some GUI tools don't use it correctly. The tools try to "simplify" Git by ignoring how the stating area is supposed to work, or ignore it completely like the infamous JetBrains IDEs. (IDEA is the tool that needed almost 10 years to implement Git sub-modules…). I think the VCS handling in IDEA is on the surface very polished. But when it comes to something like the staging area the UI-wise very crappy VS Code Git support beats that by far. Sublime Merge does also the "right thing"™ and hides the staged changes at the bottom so you see only the the changes to the changes. Exactly as the staging area is meant to be used!

saghm 4y ago
I can see the behavior being useful in some cases (and not a _super_ common cause of mistakes once you learn it), but the issue for me is mainly that it's surprising and easy to get bitten by before you learn it. This describes git entire UX as well in my opinion: the underlying model is very powerful and generally pretty sound, but the API for it does a poor job of making it clear, and generally you have to make a lot of mistakes on the way to learning how to use it properly.
- still_grokking 4y ago
  Yes, this makes sense mostly. Git is conceptually very sane and logical. But the UX is indeed (still) terrible. But a lot of people seem to complain about the complexity of the underlying concepts. That makes no sense to me as the concepts are complex because the problem at hand is complex. Also it makes no sense to me that people are constantly crying for a new tool even they have obviously issues with understanding the problem space and all requirements. A new tool would not make all this complexity go away! It could at most try to "hide" some of the complexity by introducing magic. This wouldn't be helpful at all as magic is way worse than bad UX, imho. Bad UX is bad UX you can deal with it. But when magic goes wrong all bets are off and you're usually in deep trouble. This looks like people would argue to rewrite the back-end (some propose form scratch!) even only the front-end needs some face lift…
  - saghm 4y ago
    I think the only potential improvement I can think of to the underlying model is that a patch-based system does seem like it would alleviate some of my pain points, but the UX for that hasn't exactly been fully figured out either; last time I tried pijul, it certainly seemed compelling feature-wise, but I wasn't able to figure out everything I wanted to do with it easily. It also would mostly just be a quality of life improvement for me at this point too; git is fully capable of doing everything I need it to, but sometimes I might have to google a bit to figure out how exactly to tell it what I want.

saghm 4y ago

I can see the behavior being useful in some cases (and not a _super_ common cause of mistakes once you learn it), but the issue for me is mainly that it's surprising and easy to get bitten by before you learn it. This describes git entire UX as well in my opinion: the underlying model is very powerful and generally pretty sound, but the API for it does a poor job of making it clear, and generally you have to make a lot of mistakes on the way to learning how to use it properly.

still_grokking 4y ago
Yes, this makes sense mostly. Git is conceptually very sane and logical. But the UX is indeed (still) terrible. But a lot of people seem to complain about the complexity of the underlying concepts. That makes no sense to me as the concepts are complex because the problem at hand is complex. Also it makes no sense to me that people are constantly crying for a new tool even they have obviously issues with understanding the problem space and all requirements. A new tool would not make all this complexity go away! It could at most try to "hide" some of the complexity by introducing magic. This wouldn't be helpful at all as magic is way worse than bad UX, imho. Bad UX is bad UX you can deal with it. But when magic goes wrong all bets are off and you're usually in deep trouble. This looks like people would argue to rewrite the back-end (some propose form scratch!) even only the front-end needs some face lift…
- saghm 4y ago
  I think the only potential improvement I can think of to the underlying model is that a patch-based system does seem like it would alleviate some of my pain points, but the UX for that hasn't exactly been fully figured out either; last time I tried pijul, it certainly seemed compelling feature-wise, but I wasn't able to figure out everything I wanted to do with it easily. It also would mostly just be a quality of life improvement for me at this point too; git is fully capable of doing everything I need it to, but sometimes I might have to google a bit to figure out how exactly to tell it what I want.