5 ms·
Using Git add -p for fun (and profit)
- howToTestFE 10mo agoI find the jetbrains IDEs (like Webstorm) has the best UI interface for this. Selectively commit specific lines from your changes.
- kapacuk 10mo agomagit can do that too.
- LeBit 10mo agoLazygit can do that too.
- gear54rus 10mo agoSmartGit can do that too
- insin 10mo agogit-gui can do that too
- skydhash 10mo agotig can do that too
- 1718627440 10mo agoFor all the others, that is the built-in GUI.
- andrewshadura 10mo agoHow about git-crecord?
- rogerbinns 10mo agoAnother excellent GUI is gitg. You can select specific lines for staging, but also for discarding. The latter is especially useful for temporary debug only changes that you want to throw away.
- felubra 10mo agoFor VSCode-based editors I am a happy user of the "Stage selected ranges" command
- ktpsns 10mo agoWhat's wrong with a big end of day commit? Sure, a well crafted git history can be very valuable. But then comes somebody and decides to just flush your well curated history down the toilet (=delete it and start somewhere else from scratch) and then all the valuable metadata stored in the history is lost. Maybe consider putting your energy into a good documentation inside the repository. I would love to have more projects with documentations which cover the timeline and ideas during development, instead of having to extract these information from metadata - which is what commit messages are, in the end.
- mvanbaak 10mo agoif commit messages are meaningful and the commits are well crafted (with the help of git add -p for example) this documentation can be generated from the metadata ;P Also, big end of day commits normally cover multiple different fixes. Which is, I hope you can understand, not very nice to have in one big commit. If someone else decides your implementation of something is not good enough, and they manage to get enough buy-in to rewrite it from scratch, maybe they were right to start with?. And if your history is not clear about the why of your changes, you have 0 to defend your work
- agoose77 10mo agoAlso, rebasing is a lot easier when you have small commits, rather than a mega conflict.
- a13o 10mo agoAtomic commits compose easier. In case you want to pull a few out to ship as their own topic. Or separate out the noisy changes so rebases are quicker. Separate out the machine-generated commit so you can drop it and regenerate it on top of whatever. My commit messages are pretty basic “verbed foo” notes to myself, and I’m going to squash merge them to mainline anyway. The atomic commits, sometimes aided by git add -p, are to keep me nimble in an active codebase.
- jraph 10mo ago> But then comes somebody and decides to just flush your well curated history down the toilet (=delete it and start somewhere else from scratch) and then all the valuable metadata stored in the history is lost. How does this happen? I haven't run into this. > Maybe consider putting your energy into a good documentation inside the repository I'd say both are valuable. I use git log and git blame to try to understand how a piece of code came to be. This has saved me a few times. Recently, I was about to replace something strange to something way more obvious to fix a rendering issue (like, in some HTML, an SVG file was displayed by pasting its content into the HTML directly, and I was about to use an img tag to display it instead), but the git log told me that previously, the SVG was indeed displayed using an img tag and the change was made to fix the issue that the links in the SVG were not working. I would have inadvertently reverted a fix and caused a regression. I would have missed the reason a code was like this with a big "work" end of the day commit. It would have been better if the person had commented their change with something like "I know, looks weird, but we need this for the SVG to be interactive" (and I told them btw), but it's easy to not notice a situation where a comment is warranted. When you've spent a couple of hours in some code, your change can end up feeling obvious to you. The code history is one of the strategies to understand the code, and meaningful commits help with this.
- vermon 10mo agoI'm a big fan of how tig TUI makes this, and other git actions, very simple https://jonas.github.io/tig/ https://jonas.github.io/tig/
- petepete 10mo agoI've used tig just for this for as long as I can remember, probably 18+ years.
- poly2it 10mo agoFYI: your website is barely readble with light mode.
- ellisv 10mo agoalso barely readable with dark mode
- fainpul 10mo agoDark mode looks fine to me: light gray on black. Light mode is terrible: dark gray on black.
- kaelwd 10mo agoYou get light grey? The headings are #101828 and body text #364153 on #0a0a0a for me.
- fainpul 10mo agoLight mode text: oklch(37.3% .034 259.733) Dark mode text: oklch(87.2% .01 258.338) Background in both modes: oklch(14.5% 0 0) See here: https://jsfiddle.net/kmtwf4g3/ https://jsfiddle.net/kmtwf4g3/ I think the fuckup of the website author is that the background is black instead of white in light mode. Otherwise the text colors would be fine as they are. Probably vibe coded and never tested in light mode.
- fixedprog 10mo agoNot vibe-coded! I just didn't realize that the `prose` mode with Tailwind changes the default text colour set on other pages. Lesson learned!
- fuzzythinker 10mo agoLight gray on black is not fine. Background should not be black, the text blurs.
- 10mo ago
- pseufaux 10mo agoThis is one place jj really shines. Using jj new to quickly switch to a new change makes it easier to not drop flow but still break up work. You can come back later and add descriptions or reorder and squash. That way, you don't get into as many situations where splitting a commit is necessary. For those that remain, jj split works well.
- minton 10mo agoI’ve looked at jj, but couldn’t make sense of the proposed benefits. I always stage individual files and never the entire working directory, so I’m confused how it improves that over git.
- ekipan 10mo agoI've not tried jj yet so I can only speak to impressions, and those impressions appeal to me a lot. My understanding is that jj amends all the changes in _now_ so there's only one place where changes live: the commit graph. No index, no uncommitted worktree. Just commits. And then jj supposedly gives you a lot more freedom to move through and mutate the commit graph directly, rebasing dependent work for you automatically. So instead of having to `git add -p` several times to pick apart changes from the worktree, the worktree always goes into the graph and you can `jj split` to pick them apart after. jj split # split latest commit into two jj edit @- # go back one jj describe # change message jj split # whoops, insert commit in the middle jj edit @+ # move forward again $EDITOR myfile # do some changes jj st # amend the changes and show status jj edit def # jump elsewhere in the graph jj squash # put two commits together and auto-rebase its descendants jj new abc # start working after latest # etc etc
- ekipan 10mo agoI confess I'm still pretty new to git. I haven't had a very long time to wed myself to git's index and its presence makes me do extra ceremony that I resent whenever I want to polish my graph for my personal projects. The main difference, it seems, is workflow: git's "prepare then commit" vs jj's "commit then revise". Currently I do make use of `git add -p` just like grandparent, but I also feel a psychological burden: I will often leave like 3 or 4 separate 2-line changes in the worktree because I don't wanna bother with the ceremony right now, but my perfectionism also resists me putting a lump commit. That's jj's main appeal to me. It amends my work in, then supposedly let's me sculpt it when I'm ready with less of that ceremony.
- miduil 10mo agoWait till you've start using `git commit -p -m "my commit"`.
- ethmarks 10mo agoI love Zed editor's git UI for this. If you click on the left gutter of a hunk, it opens a little interface in the top right corner that lets you either Stage or Restore that hunk.
- Someone 10mo agoA disadvantage of git add -p is that it allows you to create a commit that never existed on the development system, and, hence, cannot have been tested. How do people handle that? One way would be to follow it up with git stash, running tests, and, if necessary, git amend, but that can get cumbersome soon.
- franky47 10mo agoThat’s what CI is for.
- throwaway613745 10mo agoIt hasn't been an issue in my experience at $DAY_JOB, but for us all commits must pass CI and not just the tip of whatever branch was just pushed. So branches with partial commits that fail CI cannot be merged. So if you commit an incorrect partial commit, you either squash it into a commit that does pass CI (usually the next one forward) or you rebase and edit the failed commit and fix it and force push your branch and run CI on the whole changeset again.
- t0mas88 10mo agoIf you push a branch with many commits, does it run CI on each commit? In sequence or with some parallelism?
- y-curious 10mo agoIt runs on the last commit with the idea that it will all be squashed at merge. Are you worried about reverting some commits but not all?
- t0mas88 10mo agoThat's the normal setup, but the parent comment made it sound like theirs would build every commit?
- martinvonz 10mo ago
- tome 10mo agoIf you liked this, you're going to love git commit --verbose --patch
- yjftsjthsd-h 10mo agoYeah, I don't always use -p, but I always use -v
- fixedprog 10mo agoI'll have to try it :)
- prodigycorp 10mo agoIs there any tool that allows you to pass the line numbers that you want to stage as arguments to the command, instead of having to do it interactively?
- calvinmorrison 10mo agoI strictly use git add -p. for one, it lets me create small patches of related stuff. There's nothing wrong with major patchsets in general but it makes it harder to cherry-pick little fixes to old stable branches for example two, I notice other developers making me do the work for them because crap sneaks into their commits, like debugging statements or accidentally removed hunks. Instead I have to do "git add -p" when reviewing their commit. Essentially, it's a first pass staging area you can review what you did. beautiful.
- yx827ha 10mo agoI've been using this UI git diff add script for years: https://github.com/ismell/diffadd https://github.com/ismell/diffadd I think it works better then the TUI. Surprised something like it hasn't landed in upstream git.
- deleted 10mo ago[deleted]
- littlecranky67 10mo agoThis is the second link from the HN start page that doesn't load due to La Liga censoring in Spain.
- RunningDroid 10mo agoHere's a couple archive links that may help you get around that: https://archive.today/Ig42c https://archive.today/Ig42c (has issues with Cloudflare DNS) https://web.archive.org/web/20251214151943/https://techne98.com/blog/using-git-add-p/ https://web.archive.org/web/20251214151943/https://techne98....
- littlecranky67 10mo agoI have TOR enabled in my firefox (in a container) just for that. It just seems madness for me (as a non-spaniard) that 2 links of the HN startpage are blocked for football. We are not talking the regular terrorism, abuse/illegal content whatnot. No, censorship to protect football IP.
- gary_0 10mo agoI've been using lazygit [https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit] which is a friendly TUI that makes selecting which lines to commit relatively painless. As a heavy user of hunk-by-hunk or line-by-line commits, I used to use tortoisehg, but on my current distro its showing some bitrot, so I decided to try something else.
- kevinmchugh 10mo agoI almost exclusively use add -p. It's another moment to review my changes and it saves me from having to type out the names of the files I've changed. I don't know if I've ever committed a file unintentionally since adopting it. I like it especially in concert with git commit --amend, which lets me tack my newest changes onto the previous commit. (Though an interactive rebase with fixup is even better)
- spider-mario 10mo ago> I don't know if I've ever committed a file unintentionally since adopting it. I’ve had the opposite problem: forgetting to add new files. > I like it especially in concert with git commit --amend, which lets me tack my newest changes onto the previous commit. (Though an interactive rebase with fixup is even better) No need for the rebase to be interactive: $ git commit --fixup=<commit> $ git rebase --autosquash <base>
- s1mplicissimus 10mo ago> I’ve had the opposite problem: forgetting to add new files. Any good solutions for this around? For now I've adopted running `git status` after `git add -p` to make sure there's no untracked files, but it feels a bit clunky
- 1718627440 10mo agoYou can run the tests on the actual produced commit, if you missed some files there would be a compilation error.
- kevinmchugh 10mo agoI occasionally forget to add a new file but don't mind it much. I consider it a significantly smaller problem than committing a file that shouldn't be. CI is gonna run and my tests are surely gonna fail if I didn't commit some file. So I'll see that and commit --amend or fixup to add the new file. unless the file I forgot to commit is the tests, which hopefully I'll catch by the time of the PR
- jyscao 10mo agovim-fugitive for Vim/Neovim is even better as it allows you to do per line stages, not just per hunk. There are many other plugins for vim and emacs (e.g. magit) that enhance one’s git workflow.
- philo23 10mo agoMy two favourite bits of git add -p that aren't mentioned here: the / (search) command to search unstaged hunks for a specific keyword rather than having to jump through all the individual changes you've made when there's lots. and the e (edit) command to manually split out two changes that end up in one hunk that I'd rather have in individual commits.
- vim-guru 10mo agoThis has been the default for us using magit for years.
- EstanislaoStan 10mo agoI find `jj commit -i` much easier. Lol or they could use VSCode's integrated source control and stage stuff manually that way. Both are better than bare `git add -p` in my opinion.
- Brian_K_White 10mo agoHow can a programmer write -P in the titles when the flag is -p?
- fixedprog 10mo agoYeah I stylistically decided to set my titles in all caps, but now thinking about that I'm not sure if it was a good idea...
- s1mplicissimus 10mo agoGreat tip, I have git add -p aliased to "gap" because I use it so often