Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stash changes not in index before applying hooks #99

Open
Northo opened this issue Oct 26, 2022 · 1 comment
Open

Stash changes not in index before applying hooks #99

Northo opened this issue Oct 26, 2022 · 1 comment
Labels
bug Something isn't working enhancement New feature or request help wanted Extra attention is needed

Comments

@Northo
Copy link

Northo commented Oct 26, 2022

Hi, and thanks for developing this great tool!

Unexpected behavior:
When applying the hooks with Mookme, the hooks are run with the working tree as-is, as far as I understand. This may cause confusing behavior for files that are only partially stashed. For example, a linter may pass even when the stashed file is not acceptable.

What do you suggest:
pre-commit solves this by stashing away the working tree not in index before the hooks are run. It is obviously possible to write this manually in the hook files, but I believe it would be great if this could be added directly into Mookme.

Concrete example
I have a black formatter hook. When attempting to commit, black is run on the file, but the commit is not committed, as Mookme is set to exit on error. Now, parts of the file is staged, in an unacceptable state, and the parts that have been changed by black, are not staged. When attempting to commit anew, without first staging the new changes, the commit is accepted, as black is run against the working tree.

@LMaxence
Copy link
Member

Hello !

You are pointing out a well known limitation on my side. Having an automatic stash in Mookme is something that I had wanted for a long time.

However there is one use case I couldn't crack so far, happening relatively often: If you stash something, make a change (for instance through a formatter), and unstash the changes, it becomes very likely to end up in merge conflicts.

As far as it looks like a "normal behaviour" to me, it will definitely look like a bug to many others.

If you have some ideas about the functional design of this feature, I would happily dig into it with you :)

@LMaxence LMaxence added bug Something isn't working enhancement New feature or request help wanted Extra attention is needed labels Jan 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants