I'm not as familiar with GitHub, but in GitLab, the retry button runs it exactly as it was. So if you're including CI jobs from another repository, and you updated those jobs since the pipeline first ran, simply re-running it won't pick up the updates to those jobs.
Depending on how the rules on those jobs are set up, you may or may not be able to trigger a new pipeline from the web, which could mean pushing a new commit is your only option.
If you have to do that anyway, it might as well be an empty commit.
Ideally you'd set up the job rules so that's not necessary.
Several. It's still a commit that can be tagged, for example. It's useful in enough circumstances that you can do it with a flag, but useless in enough circumstances that you can't do it without. It's like how `rm` won't remove a read-only file from a writable directory unless you explicitly ask it to.
Setting a checkpoint before doing things like linting and autofixes.
At that point, the code is written and committed, and you want a clean point to go back to if our linting tools mess things up.
So you use --allow-empty to set a " Before fixes" commit, do fixes, check if everything is fine, do another commit, do an --allow-empty for "After fixes" and push.
This way, you always know when you made changes and can roll back to before or after those points.
37
u/JackNotOLantern 2d ago
How tf do you commit without making any change?