Magit allows selective staging/unstaging, either of hunks, or by selecting lines (AKA Emacs's "region"). I avoid staging from the git commandline, unless I'm just doing whole files.
PS: Majutsu provides this too (a magit-like tool for jj)
The per-line staging in magit is a frequent tool I use. I can be in the middle of bunch of other changes, change 1 line for a different reason that would otherwise be "mid-hunk", and the stage & commit it with its own explanation.
It releases me from having to have the "discipline" to stay 100% focused on the broader task at hand and say "hmm, I should fix that while I'm here", without co-mingling purposefully different commits.
Truly fantastic. Absurdly, I have no idea how to do this on the command line, though presumably it is possible from there too (just a lot, lot less convenient).
My biggest problem with `add -p` is correcting any patches I added or rejected by accident. Often times I skip through dozens of things I don’t want to add, then realized that last hunk was something I did need. But I can’t re-visit it, I have to start over and try extra hard to not skip past it again.
I wish the j and k shortcuts could revisit hunks I’ve already added/rejected, not just ones I haven’t reviewed yet. On a large set of unstaged changes that you mostly don’t want, it really sucks to “lose your place” in the list of hunks.
D’oh. I should have reviewed the docs better, you’re totally right. Now I feel dumb. Wish I would’ve learned this a long time ago. (Or maybe I did and forgot, perhaps multiple times. I’ve used git basically daily since 2006. I’ve forgotten a lot.)
The whole "Stage this hunk [y,n,q,a,d,k,K,j,J,g,/,e,p,P,?]?" line is pretty intimidating, but I urge anyone who still wants to understand git and be able to (themselves) use it effectively, to do "?" when you see it, read through what each action does and forcefully try them out to see what they do, in some low stakes project. Ends up being a super quick way of staging a whole bunch of work and avoiding staging other, but it's pretty weird at first glance.
it's not as easy as you said.
it can be tricky and complicated to use edit mode.
I usually use it, but still often don't understand - will this edit succeed or why it is failed.
Mercurial's `hg commit -i` with the curses interface is so much better for this it's not even funny. Fortunately I'd assume Jujutsu's UX is similar, based on arccy's comment.
In git gui, you can highlight a line and right-click to stage or unstage just that line. I just googled it and discovered it’s relatively easy to add a keyboard shortcut for it, but I’m not sure how useful that is.
I always use git add -i which is just one level up. The tui is pretty intuitive for day to day tasks, including staging partial chunks or lines of code.
I've sadly had to back out of using jj after leaning into LLM coding assistance, as, even with an extremely well-written jj guide in its context (and literally blocking the use of git), it never failed to screw things up more than if I was just using git (I call this an "LLMpedance mismatch" problem)
If LLM coding assistance continues to increase, it's going to be a rather large speed bump to cross
One of the biggest problems is actually unsolvable if you want to keep colocated Git and git tooling around, because it has to do with how jj fundamentally works: detached HEADs, detached HEADs everywhere
You yourself may not use AI, this is for those who do and are interested in switching to jj
I have a lot of things that are built around git already- such as my very commandline, which shouts in bright red if we are on DETACHED HEAD.
I know WHY detached heads happen when using jj (from git's perspective); that doesn't mean I have to LIKE it. Why can't interim worktree commits just use the most-recent bookmark, which is 99% of the time what you'd likely want anyway, is easily movable if it's not, and keeps all Git tooling (as well as old Git users like me) from getting confused?
I've been letting LLMs make commits for many months now. Perhaps that's the "problem" in my case, and why LLMs' incomplete "mental" model of jj seems to cause issues. You wouldn't see the problem if you are still manually committing. (Also, WHY are you still manually committing? LLMs are pretty great now at git committing, at least!)
> such as my very commandline, which shouts in bright red if we are on DETACHED HEAD.
Fix the command line. Mine just shows the git hash, and the color is only red if there's an uncommitted diff. It doesn't care if I'm in a detached head.
> Also, WHY are you still manually committing? LLMs are pretty great now at git committing, at least!)
Glm-5.1+ and gpt-5.5+ seem quite capable. My agents is mostly helping glm with a jj status command it would reliably try but get the quoting wrong on. It's not confused about detached head.
i've always thought one of git's strengths is offering robust aliasing and subcommand flexibility. why not spend three seconds making git have split too?
I did finally add jj-hunk to my AGENTS.md, and it's now a sizable set of instructions, to my chargrin. I haven't spent the time yet to trim it down but that's coming.
I do think that as nice as jj is, the git add -p and git rebase -i are both still tools that base jj could do much better on, that people rightfully are going to miss & feel absolutely stranded, bereft, alone for when they are not there. They are just very clear. There's other tools in jj ecosystem you can build back up by (jj-hunk for example) but the Great Filter of dev ambition to keep striving on just to get back to the core git basics is deeply winnowing.
> I do think that as nice as jj is, the git add -p and git rebase -i are both still tools that base jj could do much better on, that people rightfully are going to miss & feel absolutely stranded, bereft, alone for when they are not there
Can you elaborate? I don't know any reason I would prefer `git rebase -i` over jujutsu. Do you have an example?
Ive got a tendency to modify many things as I go and break them into commits later. Generally I do git add -p until things are too interwoven. In that case, I've ended up with the following strategy:
git commit -m "WIP" &
git revert HEAD &
git revert HEAD &
git reset HEAD^
Now I've got a copy of the changes as a commit and I'm my work tree. I widdle it down until its one change only. Then I do:
I find grepdiff and this function are pretty useful if you want to pull certain hunks out of a large change set:
#!/bin/bash
# Put this into your .bashrc, or whatever.
function git-add-regex {
git diff -U0 | grepdiff -E "$1" --output-matching=hunk | git apply --cached --unidiff-zero
}
While I see the utility of partial file commits, I think that it promotes committing untested code. Fossil scm doesn’t have an equivalent feature because of this very issue.
Committing untested code doesn’t matter at all. Merging untested code absolutely does. What you commit locally doesn’t need to correspond at all to what is even shown to others, let alone merged.
Sometimes I think the use cases for “version control I use locally on my machine” and “version control that goes up to the public repo and is reviewed” are so wildly different, it’s a wonder we even use the same tool for both.
This isn’t partial commits. It’s partial staging. This does not promote committing untested code. Committing also doesn’t promote a lack of testing, there’s no justification for that assumption.
Magit allows selective staging/unstaging, either of hunks, or by selecting lines (AKA Emacs's "region"). I avoid staging from the git commandline, unless I'm just doing whole files.
PS: Majutsu provides this too (a magit-like tool for jj)
Neogit, Magit inspired, does the same for Neovim. Would recommend!
I think you can do the same with tig and lazyvim. Sometimes you just need interactivity.
VSCode also allows staging/unstaging specific hunks by hovering over the hunk near the left/right separator in diff view - super handy when I need it!
The per-line staging in magit is a frequent tool I use. I can be in the middle of bunch of other changes, change 1 line for a different reason that would otherwise be "mid-hunk", and the stage & commit it with its own explanation.
It releases me from having to have the "discipline" to stay 100% focused on the broader task at hand and say "hmm, I should fix that while I'm here", without co-mingling purposefully different commits.
Truly fantastic. Absurdly, I have no idea how to do this on the command line, though presumably it is possible from there too (just a lot, lot less convenient).
git add -p or git add ‹file› -p
Nope. That doesn't offer per-line .. or does it ?
e in interactive mode lets you directly edit the patch line by line, so it depends how you count popping open an editor
Git gui does per-line staging, and comes with git…
In the case of a newly committed file you can add just the file with
git add . -N
And then review the text itself as part of the git add -p workflow
TIL about git add -N / --intent-to-add :
My biggest problem with `add -p` is correcting any patches I added or rejected by accident. Often times I skip through dozens of things I don’t want to add, then realized that last hunk was something I did need. But I can’t re-visit it, I have to start over and try extra hard to not skip past it again.
I wish the j and k shortcuts could revisit hunks I’ve already added/rejected, not just ones I haven’t reviewed yet. On a large set of unstaged changes that you mostly don’t want, it really sucks to “lose your place” in the list of hunks.
From skimming through the article, isn't that what the uppercase variants do?
From the article, try J and K instead of j and k; that moves to next/previous hunk, not next/previous unreviewed hunk.
To you and the sibling commenter:
D’oh. I should have reviewed the docs better, you’re totally right. Now I feel dumb. Wish I would’ve learned this a long time ago. (Or maybe I did and forgot, perhaps multiple times. I’ve used git basically daily since 2006. I’ve forgotten a lot.)
I find splitting hunks a pain. I wish I could just split by line, would be a great feature.
I've used tig for longer than I can remember for my selective staging needs.
Use 'e' in -p mode and you can edit the hunks as you wish, choose lines, etc.
The whole "Stage this hunk [y,n,q,a,d,k,K,j,J,g,/,e,p,P,?]?" line is pretty intimidating, but I urge anyone who still wants to understand git and be able to (themselves) use it effectively, to do "?" when you see it, read through what each action does and forcefully try them out to see what they do, in some low stakes project. Ends up being a super quick way of staging a whole bunch of work and avoiding staging other, but it's pretty weird at first glance.
it's not as easy as you said. it can be tricky and complicated to use edit mode. I usually use it, but still often don't understand - will this edit succeed or why it is failed.
use jj, the default is to select by line
Mercurial's `hg commit -i` with the curses interface is so much better for this it's not even funny. Fortunately I'd assume Jujutsu's UX is similar, based on arccy's comment.
> splitting hunks a pain
Sublime Merge for the win; a fantastic visual interface with context and reversible inputs. Don't leave home without it!
to make the list closer to complete, magit in emacs allows this (Ctrl-space on the line, done).
In git gui, you can highlight a line and right-click to stage or unstage just that line. I just googled it and discovered it’s relatively easy to add a keyboard shortcut for it, but I’m not sure how useful that is.
I always use git add -i which is just one level up. The tui is pretty intuitive for day to day tasks, including staging partial chunks or lines of code.
> If you’re not already using git add -p to stage your commits then you’re missing out.
After switching to jujutsu, I assure you I don't miss this feature.
jj takes the opposite approach. It keeps staging things, and you use split whenever you want to separate things out.
(And yes, it stores the staged changes as revisions, so you can always back out to a previous staged state).
I've sadly had to back out of using jj after leaning into LLM coding assistance, as, even with an extremely well-written jj guide in its context (and literally blocking the use of git), it never failed to screw things up more than if I was just using git (I call this an "LLMpedance mismatch" problem)
If LLM coding assistance continues to increase, it's going to be a rather large speed bump to cross
One of the biggest problems is actually unsolvable if you want to keep colocated Git and git tooling around, because it has to do with how jj fundamentally works: detached HEADs, detached HEADs everywhere
You yourself may not use AI, this is for those who do and are interested in switching to jj
I don't let LLMs make commits for me - git or jj.
OK, OK - I lie. For personal projects I do - some handle jj decently well. But at work I don't let it make any commits ... and it never tries to.
What tools are you using that won't work with detached heads?
I have a lot of things that are built around git already- such as my very commandline, which shouts in bright red if we are on DETACHED HEAD.
I know WHY detached heads happen when using jj (from git's perspective); that doesn't mean I have to LIKE it. Why can't interim worktree commits just use the most-recent bookmark, which is 99% of the time what you'd likely want anyway, is easily movable if it's not, and keeps all Git tooling (as well as old Git users like me) from getting confused?
I've been letting LLMs make commits for many months now. Perhaps that's the "problem" in my case, and why LLMs' incomplete "mental" model of jj seems to cause issues. You wouldn't see the problem if you are still manually committing. (Also, WHY are you still manually committing? LLMs are pretty great now at git committing, at least!)
> such as my very commandline, which shouts in bright red if we are on DETACHED HEAD.
Fix the command line. Mine just shows the git hash, and the color is only red if there's an uncommitted diff. It doesn't care if I'm in a detached head.
> Also, WHY are you still manually committing? LLMs are pretty great now at git committing, at least!)
I like to control the shape of my commit log.
Glm-5.1+ and gpt-5.5+ seem quite capable. My agents is mostly helping glm with a jj status command it would reliably try but get the quoting wrong on. It's not confused about detached head.
> jj takes the opposite approach. It keeps staging things, and you use split whenever you want to separate things out.
You can use `git reset -p` to selectively unstage hunks the same way if you wanted to.
I've used git for many years and never remembered the command `git reset -p`. I'd have to look it up. Since that's a pain, I simply didn't.
Whereas with jujutsu, after learning it once, I never looked up `split`.
And it's not like I use `split` often. I can go weeks without it.
i've always thought one of git's strengths is offering robust aliasing and subcommand flexibility. why not spend three seconds making git have split too?
And do that on every machine?
Easier to just use jujutsu. It has a lot of benefits than just this.
if you did not have alias for git reset -p you never really used git ;)
I did finally add jj-hunk to my AGENTS.md, and it's now a sizable set of instructions, to my chargrin. I haven't spent the time yet to trim it down but that's coming.
I do think that as nice as jj is, the git add -p and git rebase -i are both still tools that base jj could do much better on, that people rightfully are going to miss & feel absolutely stranded, bereft, alone for when they are not there. They are just very clear. There's other tools in jj ecosystem you can build back up by (jj-hunk for example) but the Great Filter of dev ambition to keep striving on just to get back to the core git basics is deeply winnowing.
> I do think that as nice as jj is, the git add -p and git rebase -i are both still tools that base jj could do much better on, that people rightfully are going to miss & feel absolutely stranded, bereft, alone for when they are not there
Can you elaborate? I don't know any reason I would prefer `git rebase -i` over jujutsu. Do you have an example?
(Ditto for `git add -p`)
Bring able to rapidly open history list in a text editor and rearrange and issue commands in vim is fantastic.
I don't need cli tools. It's basically a spreadsheet of history that can be directly modified, specified.
Super useful, and easy to do in the VS Code merge pane.
Ive got a tendency to modify many things as I go and break them into commits later. Generally I do git add -p until things are too interwoven. In that case, I've ended up with the following strategy:
git commit -m "WIP" & git revert HEAD & git revert HEAD & git reset HEAD^
Now I've got a copy of the changes as a commit and I'm my work tree. I widdle it down until its one change only. Then I do:
git commit -m "Bla" & git rebase -i HEAD~3 -X theirs
Them order Bla above WIP. I keep doing this "double revert" trick until the WIP no longer applies. Then done.
I find grepdiff and this function are pretty useful if you want to pull certain hunks out of a large change set:
https://gist.github.com/smuuf/76bde33d65b3dbbc2411e8519f3e6c...
The worst part of this workflow is when you accidentally run `git commit -am` at the end and destroy all of your careful staging.
IntelliJ has that since 2018, with visual change-by-change checkboxes that should go into each commit, very handy.
Vin fugitives difftool is even better
Also, you can use -p for stash push
and also for git restore
and also for `git reset`, when you added one thing by mistake.
yeah, but I'm just using `git restore -S -p`
While I see the utility of partial file commits, I think that it promotes committing untested code. Fossil scm doesn’t have an equivalent feature because of this very issue.
Committing untested code doesn’t matter at all. Merging untested code absolutely does. What you commit locally doesn’t need to correspond at all to what is even shown to others, let alone merged.
Sometimes I think the use cases for “version control I use locally on my machine” and “version control that goes up to the public repo and is reviewed” are so wildly different, it’s a wonder we even use the same tool for both.
This isn’t partial commits. It’s partial staging. This does not promote committing untested code. Committing also doesn’t promote a lack of testing, there’s no justification for that assumption.