Comment by bawolff

I'm merely the grandparent commenter, not the one you replied to directly, but I can tell you what I do for checkpointing some exploratory work or "I'll continue this next week".

I usually put it on a branch, even if this project otherwise does all its development on the main branch. And I commit it without running precommits, and with a commit message prefix "WIP: ". If it's on a branch you can even push it to not lose work if your local machine breaks/is stolen.

When it's time to get it into the main branch I rebase to squash commits into working ones.

Now, if my final commit history of say 3 commits all actually build at each commit? For personal projects, no. Diminishing returns. But in a collaborative environment: How fun will it be for future you, or your team mates, to run bisect if half the commits don't even build?

I have this workflow because it's so easy to add a feature, breaking 3 tests, to be fixed later. And formatting is bad. And now I add another change, and I just keep digging and one can end up in a "oh no, how did I end up here?" state where different binaries in the tree need to be synced to different commits to even build.

> I feel like insisting on atomic commits in your local checkout defeats the entire purpose of using a tool like git.

WIP commits is hardly the only benefit of git or other DVCS over things like subversion.

> What do you do when you are working on something and are forced to switch to working on something else in the middle of it?

`git stash` is always an option :) but even if you want to commit it, you can always undo (or `--amend`) the commit when you get back to working. I personally am also a big fan of `git rebase -i` and all the things it allows me to fix up in the history before merging (rebasing) in to the main branch.

I interpreted the parents post as: as long as my combination of commits results in something working before getting merged, it's fine.

Local wip commits didn't come to mind at all