I didn't even see that this post got any comments/views on HN - thanks for all of the comments, I've just updated it and hopefully the issues with the colours should be fixed now :)
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.
I'm in a daylit room on a laptop screen in dark mode. Some of the text was literally invisible. If the site's owner is reading this, you should fix that.
A 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.
It 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.
>A 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.
The things you commit can always be different from what you test. In fact, if you know what you are doing, it is a feature to be able to create commits like this without testing. I certainly don't need to test my "Fixed typo in comments" commits...
>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.
Well, your CI system should be testing for you. But if you must test it locally, `git rebase` can either pause between steps or execute commands between steps. Finish making commits. If you made, say, 3 commits, then do `git rebase -i HEAD~3` and do break/exec as desired.
This 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.
Your mileage may vary, because the workflow you described does not suit me. I rarely want to put on hold my commit, work on a new one, then go back later to the former commit.
Most of the time, when working on a new commit I have a few changes related to recent commits. So _when I'm done with all that_, I commit selectively the new work, then dispatch the rest among the other commits:
git add -p ; git commit
git add -u ; git absorb
Sometimes, I use `commit --fixup` instead of the automatic `absorb`. Anyway, I tried Jujutsu for a few weeks, some was good and some was bad; it didn't "shine" enough and I went back to pure Git.
I’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.
I'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
I 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.
JJ and Git seem to have different philosophies, so they cater to different users. I want my VCS to do only things I tell it to, so recording things into the index on its own and automatically rebasing commits are not things I actually want.
> I 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.
Have you realized, that Git versions the index yet? It was written by a filesystem guy, who (I think) considers the filesystem to be a shared space, so Git doesn't consider the filesystem to be its playground. Think of "git add" less of preparing things for the next commit and more of telling git that it can consider some state to be part of its world model. Your repository does not consist of everything below a directory (it can actually span across multiple randomly located directories), it does consist of everything that was once added to the repository.
> The main difference, it seems, is workflow: git's "prepare then commit" vs jj's "commit then revise".
I do the latter just fine in Git, but yes "git add" is a fundamental part of my workflow. I often add some lines already to the index and start writing the commit message, then trying something again in the working directory and either throwing it away or also adding it, before I finally commit. To me the index is a feature.
> but my perfectionism also resists me putting a lump commit
Sounds like you will use a VCS correctly.
> I don't wanna bother with the ceremony right now
I don't know what exactly you consider to be the "ceremony", but I think nearly any git GUI/TUI will let you add lines by selecting with the cursor and pressing a key. The good ones also allow you to edit this. This also works in the opposite way: removing or editing specific lines from an already existing commit. In my experience carefully adding lines results in less mistakes than adding everything and then carefully removing lines, but YMMV.
In addition to my other comment as you wrote you are not familiar with Git yet, some comparison to these commands. You can be in a commit in JJ, while in Git, you are always outside.
'jj edit' seems to correspond to 'git checkout', '@-' is '@~'. '@+' is not possible in Git, because a commit can have an arbitrary amount of children, Git might not even know about, not sure how JJ does this. @~5 is the 5th ancestor, @^5 is the fifth parent, @{5} is this ref five actions ago. This is the ref-log, which you can look at with 'git reflog' or 'git log --reflog'. 'master@{37.days.ago}' also works.
'jj split': use 'git commit --amend' and unselect changes or 'git reset --soft' to an older version, recommit the first part and then take the original commit on top. A git commit consists of a state, not of a diff so putting some commit on top of another that already contains part of the changes results in splitting the former.
'jj describe': 'git commit --amend'
'whoops, insert commit in the middle': just commit
'jj squash': either 'git reset --soft @~2' then 'git commit -c/C' or 'git reset @~' then 'git commit --amend' or 'git rebase' with squash or fixup. The later is possible from some other commit by using 'git commit --fixup' or even 'git absorb' (I think also exists in JJ).
Working in a detached state is fine, but you might want to add a ref (branch or tag, or something else) when you are finished, otherwise Git will eventually garbage-collect them (defaults to 4 weeks to 90 days depending on how you access the commit). You can push just fine to a remote, just specify the branch, i.e. 'git push origin @:branch'. You can also push to local branches to update them without checking them out with 'git push . @~7:feature/something'. Don't use pull, it is stupid, merge when you want to merge, rebase when you want to rebase, but don't do it implicitly as part of fetch.
Ask, if I glossed over something and shall elaborate.
I 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)
> 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>
I 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
Another 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.
What'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.
> 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.
When working on a feature branch it can be useful to break up your changes into logical commits. This gives you the flexibility to roll back to an earlier iteration when still working on the feature if needed.
One of my git habits is to git reset the entire feature branch just before opening a PR, then rebuild it with carefully crafted commits, where i try to make each commit one "step" towards building the feature. This forces me to review every change one last time and then the person doing code review can also follow this progression.
These benefits hold even if the branch ultimately gets squashed when merging into main/master. I also found that even if you squash when merging you can still browse back to the PR in your git repository web UI and still see the full commit history there.
It's useless for all but the code preservation part, it doesn't tell you anything.
> 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.
I would be very angry if someone deletes my work, why would I accept that? When my colleague throws my work into the bin, I will complain to my superior, they pay me for it after all.
> 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
That's what commit messages are? They provide the feature that you can click on any line in your codebase and get an explanation, why that line is there, what it is supposed to do, and how it came to be. That's very valuable and in my opinion, much more useful than a static standalone documentation.
First you think of commits as backups, then you think of them as a code distribution. Later you see them as a way to record time. What has been a useful insight to me was, what time is a prerequisite to: causality. Now I see that a VCS is less about recording actual history, but about recording evolution dependency, causality and intent. Also I perceive my work less to be about producing a final state of a codebase, but about producing part of the history of a codebase. My work output is not a single distribution of code, but documented, explainable and attributed diffs, i.e. commits.
Atomic 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.
> Maybe consider putting your energy into a good documentation inside the repository.
Commit messages are documentation.
If you have a good commit history you don't need write tons of documents explaining each decision. The history will contain everything that you need, including: when and who changed the code, what was the code change and why the code exists. You have a good interface for retrieving that documentation (git log, perhaps with -S, -G, --grep, -L and some pathspecs) without needing to maintain extra infrastructure for that and without being cluttered over time (it will be mostly hidden unless you actively search that). You also don't need to remember to update the documents, you are forced to do that after each commit.
A surprisingly large amount of devs, do the work to record data into a VCS (probably because they are told to by colleagues or superiors), but never seem to use them. Then they tell you that generating proper commits isn't all that important. Well, that's because they never actually use the VCS. By my book, only generating commits isn't really using a VCS, that is the information generation part, you also need to do queries on the collected data, otherwise yes it would be quite useless.
I think they somewhat do care about the history, but only as a backup and list of older versions and as bunch of potential merge bases. But they do not care about the history as in the evolution and causality. It really depends on what you see as the history, so it is a manifestation of a somewhat philosophical problem.
For me the point of splitting commit is not for documentation (though it can be an added benefit). It is so that you can easily rollback a feature, or cherry pick, it also makes the use of blame and bisect more natural. Anyways, that's git, it gives you a lot of options, do what you want with them. If a big end-of-day commit is fine for you, great, but some people prefer to work differently.
But that's not actually the reason I use "git add -p" the most. The way I use it is to exclude temporary code like traces and overrides from my commits while still keeping them in my working copy.
Hmm, this idea of maintaining working copies that differ from upstream strikes me as fragile and cumbersome. For a solo project, sure, whatever works. But for larger projects, IMHO this workflow is an antipattern.
To be fair, yes, it is a bit fragile and cumbersome, though it works for me.
However, it doesn't makes "git -p" less useful when the idea is to separate what you want to publish and what you want to keep in your work zone, be is your working copy or a dev branch.
As always with git, it is not very opinionated, it lets users have their own opinions, and they do! Monorepos vs many repos, rebase vs merge, clean vs honest history,... it can do it all, and I don't think the debates will ever settle on what is an "antipattern" as I don't think there is a single "right" answer.
Yeah, TIMTOWTDI, different strokes, etc... and I'm not claiming there's "one true way". I was just reacting (almost viscerally) to the idea of deliberately maintaining diffs in a stateful local env, which feels like it's begging for "works on my machine" issues. My instinct to avoid that, on principle, extends beyond project source code to "fiddly" local dev environments, seeking things like devcontainers, fully-reproducible builds for CI, etc.
if 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
Hoo boy I guess you never tried to use `git blame` on years-old shit huh? Don't push a commit for every line, but for logical units like one particular feature or issue.
>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.
This doesn't just accidentally happen. There are tools to migrate repositories and to flush ancient commits in huge repositories. If you curate your commit history, this is probably never necessary, or may only become necessary after decades.
>Maybe consider putting your energy into a good documentation inside the repository.
Commit messages are documentation for code, basically. `git blame` associates the messages with individual lines and lets you step through all the revisions.
>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.
The commit messages are for detailed information, not so much for architectural or API documentation. This doesn't mean you should get rid of commit metadata! Eventually, you will find a situation where you wonder what the hell you or someone else was doing, and the commit message will be a critical piece of the puzzle. You can also leave JIRA links or whatever in the message, although that adds a dependency on JIRA for more details.
I've been using this UI git diff add script for years: https://github.com/ismell/diffadd
I think it works better then the TUI. Surprised something like it hasn't landed in upstream git.
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.
I've been using 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.
Is 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?
My 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.
I 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.
I 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.
FYI: your website is barely readble with light mode.
I didn't even see that this post got any comments/views on HN - thanks for all of the comments, I've just updated it and hopefully the issues with the colours should be fixed now :)
also barely readable with dark mode
Dark mode looks fine to me: light gray on black.
Light mode is terrible: dark gray on black.
You get light grey? The headings are #101828 and body text #364153 on #0a0a0a for me.
Light 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/
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.
Not vibe-coded! I just didn't realize that the `prose` mode with Tailwind changes the default text colour set on other pages.
Lesson learned!
Light gray on black is not fine. Background should not be black, the text blurs.
I'm in a daylit room on a laptop screen in dark mode. Some of the text was literally invisible. If the site's owner is reading this, you should fix that.
A 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.
It 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.
If you push a branch with many commits, does it run CI on each commit? In sequence or with some parallelism?
It 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?
That depends on the forge and the configuration of the forge. See the parent of the comment you replied to. Not everyone uses squash merge.
That's the normal setup, but the parent comment made it sound like theirs would build every commit?
>A 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.
The things you commit can always be different from what you test. In fact, if you know what you are doing, it is a feature to be able to create commits like this without testing. I certainly don't need to test my "Fixed typo in comments" commits...
>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.
Well, your CI system should be testing for you. But if you must test it locally, `git rebase` can either pause between steps or execute commands between steps. Finish making commits. If you made, say, 3 commits, then do `git rebase -i HEAD~3` and do break/exec as desired.
You can run "git rebase last-tested-commit --exec='make check -j' to test a bunch of commits.
Do a git stash of working dir only after your git add -p. This was how the index/staging was meant to be used... I think
That’s what CI is for.
This 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.
Your mileage may vary, because the workflow you described does not suit me. I rarely want to put on hold my commit, work on a new one, then go back later to the former commit.
Most of the time, when working on a new commit I have a few changes related to recent commits. So _when I'm done with all that_, I commit selectively the new work, then dispatch the rest among the other commits:
Sometimes, I use `commit --fixup` instead of the automatic `absorb`. Anyway, I tried Jujutsu for a few weeks, some was good and some was bad; it didn't "shine" enough and I went back to pure Git.I’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.
I'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.
I 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.
JJ and Git seem to have different philosophies, so they cater to different users. I want my VCS to do only things I tell it to, so recording things into the index on its own and automatically rebasing commits are not things I actually want.
> I 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.
Have you realized, that Git versions the index yet? It was written by a filesystem guy, who (I think) considers the filesystem to be a shared space, so Git doesn't consider the filesystem to be its playground. Think of "git add" less of preparing things for the next commit and more of telling git that it can consider some state to be part of its world model. Your repository does not consist of everything below a directory (it can actually span across multiple randomly located directories), it does consist of everything that was once added to the repository.
> The main difference, it seems, is workflow: git's "prepare then commit" vs jj's "commit then revise".
I do the latter just fine in Git, but yes "git add" is a fundamental part of my workflow. I often add some lines already to the index and start writing the commit message, then trying something again in the working directory and either throwing it away or also adding it, before I finally commit. To me the index is a feature.
> but my perfectionism also resists me putting a lump commit
Sounds like you will use a VCS correctly.
> I don't wanna bother with the ceremony right now
I don't know what exactly you consider to be the "ceremony", but I think nearly any git GUI/TUI will let you add lines by selecting with the cursor and pressing a key. The good ones also allow you to edit this. This also works in the opposite way: removing or editing specific lines from an already existing commit. In my experience carefully adding lines results in less mistakes than adding everything and then carefully removing lines, but YMMV.
In addition to my other comment as you wrote you are not familiar with Git yet, some comparison to these commands. You can be in a commit in JJ, while in Git, you are always outside.
'jj edit' seems to correspond to 'git checkout', '@-' is '@~'. '@+' is not possible in Git, because a commit can have an arbitrary amount of children, Git might not even know about, not sure how JJ does this. @~5 is the 5th ancestor, @^5 is the fifth parent, @{5} is this ref five actions ago. This is the ref-log, which you can look at with 'git reflog' or 'git log --reflog'. 'master@{37.days.ago}' also works.
'jj split': use 'git commit --amend' and unselect changes or 'git reset --soft' to an older version, recommit the first part and then take the original commit on top. A git commit consists of a state, not of a diff so putting some commit on top of another that already contains part of the changes results in splitting the former.
'jj describe': 'git commit --amend'
'whoops, insert commit in the middle': just commit
'jj squash': either 'git reset --soft @~2' then 'git commit -c/C' or 'git reset @~' then 'git commit --amend' or 'git rebase' with squash or fixup. The later is possible from some other commit by using 'git commit --fixup' or even 'git absorb' (I think also exists in JJ).
Working in a detached state is fine, but you might want to add a ref (branch or tag, or something else) when you are finished, otherwise Git will eventually garbage-collect them (defaults to 4 weeks to 90 days depending on how you access the commit). You can push just fine to a remote, just specify the branch, i.e. 'git push origin @:branch'. You can also push to local branches to update them without checking them out with 'git push . @~7:feature/something'. Don't use pull, it is stupid, merge when you want to merge, rebase when you want to rebase, but don't do it implicitly as part of fetch.
Ask, if I glossed over something and shall elaborate.
I 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)
> 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:
> 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
I 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
You can run the tests on the actual produced commit, if you missed some files there would be a compilation error.
I find the jetbrains IDEs (like Webstorm) has the best UI interface for this. Selectively commit specific lines from your changes.
For VSCode-based editors I am a happy user of the "Stage selected ranges" command
Another 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.
How about git-crecord?
magit can do that too.
Lazygit can do that too.
SmartGit can do that too
git-gui can do that too
For all the others, that is the built-in GUI.
tig can do that too
What'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.
> 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.
When working on a feature branch it can be useful to break up your changes into logical commits. This gives you the flexibility to roll back to an earlier iteration when still working on the feature if needed.
One of my git habits is to git reset the entire feature branch just before opening a PR, then rebuild it with carefully crafted commits, where i try to make each commit one "step" towards building the feature. This forces me to review every change one last time and then the person doing code review can also follow this progression.
These benefits hold even if the branch ultimately gets squashed when merging into main/master. I also found that even if you squash when merging you can still browse back to the PR in your git repository web UI and still see the full commit history there.
> What's wrong with a big end of day commit?
It's useless for all but the code preservation part, it doesn't tell you anything.
> 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.
I would be very angry if someone deletes my work, why would I accept that? When my colleague throws my work into the bin, I will complain to my superior, they pay me for it after all.
> 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
That's what commit messages are? They provide the feature that you can click on any line in your codebase and get an explanation, why that line is there, what it is supposed to do, and how it came to be. That's very valuable and in my opinion, much more useful than a static standalone documentation.
First you think of commits as backups, then you think of them as a code distribution. Later you see them as a way to record time. What has been a useful insight to me was, what time is a prerequisite to: causality. Now I see that a VCS is less about recording actual history, but about recording evolution dependency, causality and intent. Also I perceive my work less to be about producing a final state of a codebase, but about producing part of the history of a codebase. My work output is not a single distribution of code, but documented, explainable and attributed diffs, i.e. commits.
Atomic 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.
> Maybe consider putting your energy into a good documentation inside the repository.
Commit messages are documentation.
If you have a good commit history you don't need write tons of documents explaining each decision. The history will contain everything that you need, including: when and who changed the code, what was the code change and why the code exists. You have a good interface for retrieving that documentation (git log, perhaps with -S, -G, --grep, -L and some pathspecs) without needing to maintain extra infrastructure for that and without being cluttered over time (it will be mostly hidden unless you actively search that). You also don't need to remember to update the documents, you are forced to do that after each commit.
And that's not a hack, Git was made for that.
A surprisingly large amount of devs, do the work to record data into a VCS (probably because they are told to by colleagues or superiors), but never seem to use them. Then they tell you that generating proper commits isn't all that important. Well, that's because they never actually use the VCS. By my book, only generating commits isn't really using a VCS, that is the information generation part, you also need to do queries on the collected data, otherwise yes it would be quite useless.
Agreed. If they don't care about the history, they don't need a vcs. There's no point in keeping a history if the history isn't helpful
I think they somewhat do care about the history, but only as a backup and list of older versions and as bunch of potential merge bases. But they do not care about the history as in the evolution and causality. It really depends on what you see as the history, so it is a manifestation of a somewhat philosophical problem.
For me the point of splitting commit is not for documentation (though it can be an added benefit). It is so that you can easily rollback a feature, or cherry pick, it also makes the use of blame and bisect more natural. Anyways, that's git, it gives you a lot of options, do what you want with them. If a big end-of-day commit is fine for you, great, but some people prefer to work differently.
But that's not actually the reason I use "git add -p" the most. The way I use it is to exclude temporary code like traces and overrides from my commits while still keeping them in my working copy.
Hmm, this idea of maintaining working copies that differ from upstream strikes me as fragile and cumbersome. For a solo project, sure, whatever works. But for larger projects, IMHO this workflow is an antipattern.
To be fair, yes, it is a bit fragile and cumbersome, though it works for me.
However, it doesn't makes "git -p" less useful when the idea is to separate what you want to publish and what you want to keep in your work zone, be is your working copy or a dev branch.
As always with git, it is not very opinionated, it lets users have their own opinions, and they do! Monorepos vs many repos, rebase vs merge, clean vs honest history,... it can do it all, and I don't think the debates will ever settle on what is an "antipattern" as I don't think there is a single "right" answer.
Yeah, TIMTOWTDI, different strokes, etc... and I'm not claiming there's "one true way". I was just reacting (almost viscerally) to the idea of deliberately maintaining diffs in a stateful local env, which feels like it's begging for "works on my machine" issues. My instinct to avoid that, on principle, extends beyond project source code to "fiddly" local dev environments, seeking things like devcontainers, fully-reproducible builds for CI, etc.
if 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
Also, rebasing is a lot easier when you have small commits, rather than a mega conflict.
>What's wrong with a big end of day commit?
Hoo boy I guess you never tried to use `git blame` on years-old shit huh? Don't push a commit for every line, but for logical units like one particular feature or issue.
>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.
This doesn't just accidentally happen. There are tools to migrate repositories and to flush ancient commits in huge repositories. If you curate your commit history, this is probably never necessary, or may only become necessary after decades.
>Maybe consider putting your energy into a good documentation inside the repository.
Commit messages are documentation for code, basically. `git blame` associates the messages with individual lines and lets you step through all the revisions.
>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.
The commit messages are for detailed information, not so much for architectural or API documentation. This doesn't mean you should get rid of commit metadata! Eventually, you will find a situation where you wonder what the hell you or someone else was doing, and the commit message will be a critical piece of the puzzle. You can also leave JIRA links or whatever in the message, although that adds a dependency on JIRA for more details.
I've been using this UI git diff add script for years: https://github.com/ismell/diffadd I think it works better then the TUI. Surprised something like it hasn't landed in upstream git.
I 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.
I've been using 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.
Is 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?
My 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.
This is the second link from the HN start page that doesn't load due to La Liga censoring in Spain.
Here's a couple archive links that may help you get around that:
https://archive.today/Ig42c (has issues with Cloudflare DNS)
https://web.archive.org/web/20251214151943/https://techne98....
I 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.
I'm a big fan of how tig TUI makes this, and other git actions, very simple https://jonas.github.io/tig/
I've used tig just for this for as long as I can remember, probably 18+ years.
I 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.
How can a programmer write -P in the titles when the flag is -p?
Yeah 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...
I 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.
Great tip, I have git add -p aliased to "gap" because I use it so often
If you liked this, you're going to love
Yeah, I don't always use -p, but I always use -v
I'll have to try it :)
vim-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.
This has been the default for us using magit for years.
Wait till you've start using `git commit -p -m "my commit"`.