I find splitting hunks a pain. I wish I could just split by line, would be a great feature.
to make the list closer to complete, magit in emacs allows this (Ctrl-space on the line, done).
Staging patches with git add (2024)
31–40 of 54 posts
Re: Staging patches with git add (2024)
#32In 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 :
git add --intent-to-add .
git diff
git add -p .
## To then reset and keep changes
## these are equivalent:
# git reset .
# git reset --mixed .Re: Staging patches with git add (2024)
#33While 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.
Re: Staging patches with git add (2024)
#34My 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.…
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.)
Re: Staging patches with git add (2024)
#35While 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.
Re: Staging patches with git add (2024)
#36> 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 bigges…
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.
Re: Staging patches with git add (2024)
#37While 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.
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.
Re: Staging patches with git add (2024)
#38Magit 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)
Git gui does per-line staging, and comes with git…
Re: Staging patches with git add (2024)
#39> 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 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.
Re: Staging patches with git add (2024)
#40I find splitting hunks a pain. I wish I could just split by line, would be a great feature.
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.