- needing to memorize branch names for easy use: there is tab completion for this;
- differences between staged and pushed commits: I'm not sure what you refer here. the closest concept to the "stage" term is "staged changes". this is by design; the idea is that while one applies changes within a single commit, some are definitive, some are evolving; for this workflow, it's very convenient. if one doesn't want, they can just add all and commit (preferrably, with a single alias ;-)).
The "most extensive" Git UX problem is possibly the excess of functionality given to the `checkout` command, which in fact is being split.
(I don't imply that Git UX is good, though)
It absolutely is. The whole "branch" paradigm evokes topology. The visual structure of the thing you're working with ought to be made clear to you, the user.
If a GUI has trouble when the workflow deviates from normalcy, it's just not powerful enough.
That being said, there will always be users who prefer the command line, and that's totally fine.
- visualise the project in its current state which may spread across several feature branches all coming in and out of master
- code preview (hugely valuable) across one or more files
- see your branches
- see your stashes
- remotes, etc
- all of the above across multiple, simultaneous, projects.
Large projects can be difficult to manage if you don't have context and oversight, which is harder to obtain from the CLI.
Of course we can get this information from the prompt but it is much more difficult to get the information in an easier-to-consume fashion.
I use Tig as well, but more often than not the git cli is sufficient.
I don't know why, but I've always felt uncomfortable using git in a GUI, but I know a lot of people who love it.
For some reason, anytime I try to use a GUI, I don't feel like I'm really doing git, if that makes any sense. Also, I've personally never felt the need to see the branches visually. And if I do get the itch to 'see' them, nothing a quick
git log --oneline --graph
cant fix!