Hacker News Reader

Comment by Groxx | Hacker News Reader

`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.

View on HN

git gui, which comes with git, is quite efficient to do partial commits. I wrote an article about this a few years ago: https://agateau.com/2016/an-intro-to-git-gui/

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.

I very much agree to this. I almost always use “git add -p”.

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.

Reply on news.ycombinator.com