3 ms·

It has an interactive commit staging command which accomplishes the same thing. In that case, it unifies the staging area with regular commits, which means you

It has an interactive commit staging command which accomplishes the same thing. In that case, it unifies the staging area with regular commits, which means you can also manipulate them the same way as regular commits. AFAICT there are only two workflows involving the staging area: staging partial commits and resolving conflicts. The first case is taken care of by partial commit support, and the second case presumably has its own dedicated mechanism.

saghm 4y ago
My favorite example of the staging area being super weird is `git diff` behavior. By default, git diff will show unstaged changes as well as committed changes, but _not_ staged changes; to see staged changes, you need to use `--cached`. This is especially weird when diffing between a fixed point (e.g. a commit hash) while going through the motions. If it's not clear why this would be weird, try out the following: * get the hash of the HEAD commit * run `git diff <hash>` and see that there are no changes * make some change to a file * run `git diff <hash>` again and see the change you made * stage the change with `git add` * run `git diff <hash>` again and no changes are show! * commit the change * run `git diff <hash>` again and the changes are back It's super bizarre to me that there would be some sort of intermediate state where changes aren't visible. I feel like it would make more sense to have some sort of formatting difference indicating unstaged versus staged but not committed versus committed, but I imagine changing that now would break all sorts of scripts, so we're stuck with it.
- sdiacom 4y ago
  Not to subtract from your point at all, but newer versions of Git allow you to use `--staged` as a synonym for `--cached`. That this is the default behaviour still makes no sense, but at least the name does.
  - saghm 4y ago
    Ah, that is a better name! I'll have to add that to my mental list of git UX improvements (I'm also a big proponent of `git switch`)
  - ajkjk 4y ago
    That's good to know, but one has to wonder why that didn't change 15 years ago. It's representative of the general problem with Git: no particular problem with having bad UX for a long time without improving it. It seems like things started to get better in the last few years, but seriously it's not like the problems weren't obvious for a long time.
- still_grokking 4y ago
  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

saghm 4y ago

My favorite example of the staging area being super weird is `git diff` behavior. By default, git diff will show unstaged changes as well as committed changes, but _not_ staged changes; to see staged changes, you need to use `--cached`. This is especially weird when diffing between a fixed point (e.g. a commit hash) while going through the motions. If it's not clear why this would be weird, try out the following: * get the hash of the HEAD commit * run `git diff <hash>` and see that there are no changes * make some change to a file * run `git diff <hash>` again and see the change you made * stage the change with `git add` * run `git diff <hash>` again and no changes are show! * commit the change * run `git diff <hash>` again and the changes are back It's super bizarre to me that there would be some sort of intermediate state where changes aren't visible. I feel like it would make more sense to have some sort of formatting difference indicating unstaged versus staged but not committed versus committed, but I imagine changing that now would break all sorts of scripts, so we're stuck with it.

sdiacom 4y ago
Not to subtract from your point at all, but newer versions of Git allow you to use `--staged` as a synonym for `--cached`. That this is the default behaviour still makes no sense, but at least the name does.
- saghm 4y ago
  Ah, that is a better name! I'll have to add that to my mental list of git UX improvements (I'm also a big proponent of `git switch`)
- ajkjk 4y ago
  That's good to know, but one has to wonder why that didn't change 15 years ago. It's representative of the general problem with Git: no particular problem with having bad UX for a long time without improving it. It seems like things started to get better in the last few years, but seriously it's not like the problems weren't obvious for a long time.
still_grokking 4y ago
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