Skip to content

feat: fail on fix by default#31

Open
movabo wants to merge 2 commits intomasterfrom
feat/fail-on-fix
Open

feat: fail on fix by default#31
movabo wants to merge 2 commits intomasterfrom
feat/fail-on-fix

Conversation

@movabo
Copy link

@movabo movabo commented Mar 11, 2026

Rationale behind each of the changes:

  • fix = true: autofix now changed to whether the fixes are automatically applied and commited, which then next line then defines: fail_on_fix = !autofix
  • Removing stash = "git": That option, together with (implicit) stage = true had the effect that the autofix changes were directly staged to the commit. The stash, however seemed to be empty when testing locally, making it hard to verify what the autofix actually did. Therefore I changed it to the recommended behavior (by deleting this line and adding)
  • stage = false: This seems to me the most intuitive behavior. Now, no changes are made to the staged code. Changes by autofix are directly visible to with git diff and need to be added manually (but I'd argue that should simply be part of the workflow).

Rationale behind each of the changes:

* `fix = true`: autofix now changed to whether the fixes are automatically applied and commited, which then next line then defines: `fail_on_fix = !autofix`
* Removing `stash = "git"`: That option, together with (implicit) `stage = true` had the effect that the autofix changes were directly staged to the commit. The stash, however seemed to be empty when testing locally, making it hard to verify what the autofix actually did. Therefore I changed it to the recommended behavior (by deleting this line and adding)
* `stage = false`: This seems to me the most intuitive behavior. Now, no changes are made to the staged code. Changes by autofix are directly visible to with `git diff` and need to be added manually (but I'd argue that should simply be part of the workflow).
@movabo movabo requested a review from stempler March 11, 2026 08:16
@stempler
Copy link
Member

Trying to understand what effect the changes will have:

Default workflow

New default workflow would be to apply fixes, but fail the commit so the changes can be reviewed.

If you have unstaged changes when committing, the fixes will also run on these, meaning compared to before changes that are not intended to be committed yet are processed, including potential work in progress.
The documentation doesn't mention that this also applies to checks, but could also be an oversight in the docs and would need to be tested. If it is the case it can have the effect that a commit is rejected based on unstaged changes.

The previous behavior though is similar if there is a check failing that requires running the fix. Running hk fix after the failed commit uses the default settings (stage=false,stash=none) and thus has the same effect related to applying the fix.

TLDR: It should be tested if checks run on unstaged changes and can present commits.

I'll try that out to check the behavior.

Autofix workflow

Automatically apply fixes and commit.

I think for this we would still want stage and stash settings as before, so fixes are included in the commit (stage) and unstaged changes are not processed. What do you think @movabo ?

@movabo
Copy link
Author

movabo commented Mar 13, 2026

If you have unstaged changes when committing, the fixes will also run on these, meaning compared to before changes that are not intended to be committed yet are processed, including potential work in progress.

Yes.

The documentation doesn't mention that this also applies to checks, but could also be an oversight in the docs and would need to be tested. If it is the case it can have the effect that a commit is rejected based on unstaged changes.

That's true.

TLDR: It should be tested if checks run on unstaged changes and can present (I guess you meant "prevent") commits.

From my test that I just did this seems true.

Unfortunately, it seems that the combination of fix = false, fail_on_fix = true, and stash = "git" doesn't seem to work. For me, it did not fix a simple indentation fix. So from what I gathered that means we have the following three options:

  1. Keep the current behavior
  2. Use the behavior in this commit, meaning that a non-staged file could prevent a commit and that non-staged WIP files could be modified
  3. Use behavior stage = true and stash = "git", meaning that it'd be hard to find out which code was modified by the fix-step

After further investigating, I find case 2 to be the worst case: It can prevent commits even though the code to be commited is fine.
Personally, I'd say case 3 is the most favorable, because honestly: When I see that spotless does not work, I'll run spotlessApply and that's it anyway. As long as we can make sure that the fix command does not break code (which for me is the case for simple code formatting), I'd be for case 3.

Stashing does not seem to work with fail on fix.
To avoid commits being rejected, this change stashes unstaged changes and then stages the fixes.
@stempler
Copy link
Member

What speaks against fail_on_fix = true with stage = false for the default workflow?
According to the docs for fail_on_fix this is how it is intended to be used.
You said

Removing stash = "git": That option, together with (implicit) stage = true had the effect that the autofix changes were directly staged to the commit

but I did not find any hint that the stash and stage settings are somehow dependent.

@movabo
Copy link
Author

movabo commented Mar 13, 2026

What speaks against fail_on_fix = true with stage = false for the default workflow?

That's definitely a fourth possibility I missed mentioning. I dislike this configuration because then again, unstaged changes could prevent a commit.
I think what I dislike quite a bit is not using the staged option and unfortunately, that option does not work with stashing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants