rant, git, UX
So here's a good example of how git actually isn't very intuitive at all:
- A common action before commit is to *stage* changes
- You do this with a command called git *add*
- To view the staged changes, you have to run git diff with the *cached* flag
Why are three entirely different terms used here to refer to the same thing?
(That is a rhetorical question, btw)
re: rant, git, UX
@cadey Oh, for sure. I understand that it's not trivial to change, too. This is more a response to the entirely-too-many people who will jump high and low to insist that Git has great UX, actually
re: rant, git, UX
@joepie91 yeah, its a pain. You may have nerd-sniped me into writing about this though. I have another bone to pick with the idea of "stacked multi-repo pull requests" that I need to work through.
re: rant, git, UX
@joepie91 speaking of, here's another related gripe:
rm is not the inverse operation of add, reset and restore --staged both are!
rant, git, UX
@joepie91 that's why i enjoy where sapling (by Facebook) wants to go. It seems a lot more user friendly with their cli. (but has sadly awful ecosystem constraints)
re: rant, git, UX
@joepie91 this happens because git was made by hackers, not designers. A lot of the "random changes" we shit on designers for are usually done to simplify these kinds of sharp edges. I think that discrepancy can be fixed, but so many people have muscle memory for git add that it may have to remain a command even if you rename it to git stage.
I fully support this idea though!