`git add -p` does that as well, it's effectively what the GUIs are using. You can also [e]dit each thing and rewrite as desired, though it can be a bit fiddly.
UIs can be nicer though for rewriting / making finer-grained splits than the hunks that -p decides on, definitely agreed there. I have broken out a UI just to simplify staging some gnarly commits. GUIs are also often nicer for understanding and resolving nasty three-way merge conflicts.
I haven't actually tried git-gui, only gitk... I'll have to give it a try, thanks :) A first-party GUI actually gives me some hope for correct behavior. gitk is broadly excellent for example and performs great, though other GUIs do some things more smoothly - exactly what I'd want in a first-party GUI.
>To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?!
I repeatedly run into this using the interactive features.
tbh I think the staging area (and popularizing local branches) may be git's greatest contribution. being able to selectively build a commit is a game-changer for creating understandable histories, and stopping local-tweak "leakage".
distributed VCS is neat and all, but the vast, vast majority of cases have a canonical source-of-truth repo somewhere, and the rest are effectively just private mirrors. for those cases, distributed is mostly a significant source of complexity rather than capability. though it is significant to have an "escape hatch" when you need it.
UIs can be nicer though for rewriting / making finer-grained splits than the hunks that -p decides on, definitely agreed there. I have broken out a UI just to simplify staging some gnarly commits. GUIs are also often nicer for understanding and resolving nasty three-way merge conflicts.