this post was submitted on 07 Aug 2025
87 points (98.9% liked)
Programming
22107 readers
292 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The cli because it is consistent everywhere and has all fearures
The only thing I'm missing in the CLI is easy picking and choosing which change to include in a commit on a more fine grained basis than files. I sometimes have a changed file and the changes fix different issues and thus should get separate commits but with the CLI I can't easily select the changes to be staged. At least not AFAIK.
Edit: Richards law of posting something wrong to get fast correct answers seems to stay true, even on lemmy. Thanks for teaching me something today <3
Uhhh,
git add -p?the best git command
Hard agree haha, use this one constantly.
You can via git add -i foo.bar
I believe the only issue with that is that it can only go by hunks. If your changes are sufficiently far away, you can select them separately. But if you change one function that should be in patch a, and another function 5 lines down that should be in patch b, I think you're screwed
That being said, this is all from memory, so don't quote me on it
In interactive add mode you can use
sto split a hunk, andeto edit it. That's usually enough for me to split things up.I usually use
git add -pto selectively stage hunks. But ingit add -iI think running thepatchcommand does the same thing to get into patch mode.If patch mode shows you a hunk, and you only want some of the lines you can press
sto split into smaller hunks. Then you'll be prompted whether to add each smaller hunk separately.If you want to stage a change that is on the same line as a change you don't want to stage, or on an adjacent line, then you need to use
eto edit the hunk. Git stages whatever changes are left when you're done editing. The file in the working tree on disk is unchanged.git gui is nice for this.
(or jj split).
Same, because its UX is actually really good. Years ago when I was new to git, I tried to use Sourcetree to revert a merge commit, and it would just fail. When I tried it in the CLI, it still failed, but it told me how to fix it. (I needed to specify which parent)
That, plus it’s scriptable, plus I’m in the terminal a lot anyway. I’ll also use the IDE git client sometimes if that’s where I am at the moment.
CLI first here too, for the same reason.
I'm not above using an editor plugin if it's simple and reliable and right there waiting, like VSCodium.
Jah, mein fearures