Commit the part you meant to commit.

Three levels, not two

Most clients stage a file or a hunk and stop there. A hunk is whatever distance Git decided to put between two edits, which often means your fix and your stray print statement arrive as one block. FluxGit goes one level further down: inside a hunk, each change is its own target, so you can stage the two lines you meant and leave the rest where they are.

Stage, unstage and discard all work at the same three levels. Nothing is a different dialog, a different mode or a different screen; the action sits next to the change it acts on.

Like git add -p, without answering the questions in order

git add -p is a queue: it shows you a hunk, asks, and moves on. To reach the fifth change you answer four times, and to reach a single line inside a hunk you split with s and edit the patch by hand with e. That is fine work, and it is strictly sequential.

A diff on screen is random access. You see the whole file, jump to the change you care about, act on it, and leave the rest untouched. That difference - sequential versus reaching straight for what you want - is the reason people who otherwise live in the terminal open a client for this one job.

A partial discard is still recoverable

Staging part of a file is safe: the work is still there. Discarding part of a file is not, which is why most tools ask you to confirm and then hope you meant it.

FluxGit captures a safety snapshot before a partial discard runs, so the change you threw away has somewhere to come back from. The same rule holds everywhere in the app: preview, risk, and a way back, before anything destructive happens - not a dialog that shifts the responsibility to you.

What this is not

The smallest unit is a change inside a hunk, not any set of lines you paint with the mouse. If a single change spans six lines, it stages as six lines. Dragging across arbitrary line ranges is not what this does, and saying otherwise would be easy and wrong.