[Someone]

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.

[throwaway613745]

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.

[t0mas88]

If you push a branch with many commits, does it run CI on each commit? In sequence or with some parallelism?

[y-curious]

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?

[martinvonz]

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.

[t0mas88]

That's the normal setup, but the parent comment made it sound like theirs would build every commit?

[wakawaka28]

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

[1718627440]

You can run "git rebase last-tested-commit --exec='make check -j' to test a bunch of commits.

[hbogert]

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

[franky47]

That’s what CI is for.