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.

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.

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