Oliver Steele

Something I maybe didn't make clear enough is that I actually don't want the fine-grained history in the repository. I might make a checkpoint every five minutes, and many of these checkpoints are pretty low quality; I don't want them persisted.

It would be nice to have all the checkpoints persisted until the next persistable commit, and then blow them away at that point. (I just made up "persistable commit" to mean one that I want to keep in the repository, as opposed to the ones that represent ephemeral checkpoints, if I implement checkpointing as commit.) The alternative for doing that that I mention is to commit checkpoints, and then rebase them away. One disadvantage of doing this is the extra step of the rebase, along with having to remember where to rebase from. The other is that "git diff head" won't tell me what I want. Maybe tagging every persistable commit solves both these problems.

Or I could, as you suggest, make a branch, commit my checkpoints into it, "merge -squash" it into the target branch, and then delete the branch. Then a persistable commit becomes "git checkout {original}; git merge --squash wip; git commit; git checkout -b wip", where {original} depends on which branch I started from. And "git diff head" becomes "git diff {original}", where, again, {original} depends on where I started. This is heavier weight than I want, but again, maybe some scripting and/or tags makes it easier.

Right now I like the fact that "git checkout head .", "git stash", and "git checkout -m -b" operate on everything since the last persistable commit. All those things would be harder, or I'd need to write more scripts/tagging to do them, if checkpoints were commits too.

Anyway, I really started out trying to draw a picture of how the index fit in, not to try to promote my particular workflow. I've added a disclaimer paragraph to try to make this clearer.