Commit the part you meant to commit.
You fixed the bug. On the way you renamed a variable, deleted a stale comment and left a print statement in. Those are not one commit, and splitting them afterwards is worse than never mixing them.
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. FluxGit captures that safety snapshot for partial discard. Elsewhere, each destructive action shows its operation-specific preview, risk and available recovery context before it runs; actions without a checkpoint stay explicitly marked.
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.
Watch: commit the fix and leave the debug print unstaged
Follow two edits in one file: stage the fix, inspect the staged change, and commit it while the debug print stays in the working tree. The narration also explains the equivalent intent with git add -p.
Watch on YouTube — opens a new tab
Recorded in a test repository. This example uses two text edits in one file. Undo is explained in the narration, not executed in this recording.
Read the English narration transcript
- You fixed a bug, and in the same file you left a debug print. You want a clean commit: the fix, without the print.
- Here is the file in FluxGit: app.py, with two changes.
- Here is why it works. Git does not commit your folder; it commits the staging area. Both changes start on disk only. Stage change puts only the fix in the staging area. The commit takes exactly that, and the debug print stays on your disk, uncommitted.
- Open the file. The diff shows both changes, and each one has its own Stage change button.
- Stage change on the fix. Only that change moves; the print stays where it is.
- Back in the commit panel: the fix is staged, the print is not.
- Write the message, and commit.
- The new commit holds the fix, and only the fix. The print is still on your disk, uncommitted.
- Changed your mind? Undo takes the commit back. The fix returns to the staging area, and your files do not change.
- In the terminal, the same is git add with dash p: Git asks about each change, you answer yes to the fix and no to the print, then commit.
- Recap. Stage changes, not whole files. One idea per commit. And Undo if you slip. Next lesson: fix the last commit.
Related features
- Semantic diff shows structural change where the language can be parsed, with a labeled fallback where it cannot.
- Commit Studio keeps the diff and the message on screen together while you write.
- Safety rails are the same preview-and-restore-point rule applied to the dangerous operations.
- Visual history is where the commit you just built goes, and where you compare it against any other.