3 ms·

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

by Someone 10mo ago

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.

franky47 10mo ago
That’s what CI is for.
throwaway613745 10mo ago
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 10mo ago
  If you push a branch with many commits, does it run CI on each commit? In sequence or with some parallelism?
  - y-curious 10mo ago
    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?
    - t0mas88 10mo ago
      That's the normal setup, but the parent comment made it sound like theirs would build every commit?
    - martinvonz 10mo ago
      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.
1718627440 10mo ago
You can run "git rebase last-tested-commit --exec='make check -j' to test a bunch of commits.
hbogert 10mo ago
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
wakawaka28 10mo ago
>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.

by Someone 10mo ago

franky47 10mo ago

That’s what CI is for.

throwaway613745 10mo ago

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 10mo ago
If you push a branch with many commits, does it run CI on each commit? In sequence or with some parallelism?
- y-curious 10mo ago
  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?
  - t0mas88 10mo ago
    That's the normal setup, but the parent comment made it sound like theirs would build every commit?
  - martinvonz 10mo ago
    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.

1718627440 10mo ago

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

hbogert 10mo ago

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

wakawaka28 10mo ago

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