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.

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.

also barely readable with dark mode

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

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.

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.

magit can do that too.

How about git-crecord?

> 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.

> 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.

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.

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.

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

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.

> 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>

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've used tig just for this for as long as I can remember, probably 18+ years.

Yeah, I don't always use -p, but I always use -v