I use magit. You want a UI that allows you to easily see the changes in your worktree and add those line by line to the index, if necessary. Of course, you also want it to be easy to add whole files or hunks too, as always going line by line would be insane.
A good commit means a good version. That's what we're doing after all: version control. Every commit you produce should be a valid standalone version of the software. Commits can build on each other, e.g. you can add feature a then subsequently add feature b that depends on feature a, but a maintainer should always be able to only take feature a, there shouldn't be bits of feature b in there, and there shouldn't be fixes for feature a in feature b's commit.
With practice you can learn to make rough commits first then clean them up into proper commits later. For example, there are "end of day" commits and there are fixup commits. Those are both valid uses of git, but you shouldn't be exposing those to your team. You need to rebase them before sending them. A good git user will sow the seeds for a smooth rebase early.
That's not really a CLI, though, it's a really basic rudimentary text UI. Might as well spend the effort to learn it learning enough Emacs to use Magit. Can it even do line by line effectively? What about unstaging stuff you added accidentally? It's not a patch on Magit or even any semi-decent GUI.
Heh fair enough. For me, it comes with the advantages of the CLI that I care about (primarily: easily accessible with the keyboard, and launching without delay) without having to adopt a different editor.
I don't need line-by-line usually (but it can technically do it if needed), but undoing accidental adds is indeed a bit of a pain.
Eh? Emacs is the complete opposite of an elitist culture. The entire point of Emacs and free software in general is to destroy the elite (developers) and put the users (me) in control.
