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

Feature request: Commit formatted files automatically in a pre commit hook #22

Open
chgsit00 opened this issue Mar 17, 2022 · 3 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@chgsit00
Copy link

Is it possible to use ReGitLint in a way to auto-commit formatted file?
I'm currently using this in my pre-commit hook:
dotnet regitlint -f staged --format-only

But all it does when executing is commiting the unformated files. The format fixes are applied to the files, but then I have to save all modified files manually to make them appear as unstaged changes. Is there a way to format all files, save the changes, stage the changed made by ReGitLint and commit them using only one commit?

@sethreno sethreno added enhancement New feature or request and removed enhancement New feature or request labels Mar 19, 2022
@sethreno
Copy link
Owner

Personally I don't have that much trust in resharper and I'm not sure I want to add an option that encourages this. I think best practice is to abort the commit if formatting is needed. If you add the --fail-on-diff option it will abort the commit and allow you to review the modifications, edit if necessary, then re-stage and commit.

If you really want to throw caution to the wind. You could probably change your pre-commit hook to perform the steps you described. Something like this:

dotnet regitlint -f staged --format-only
git diff --name-only --cached | xargs -l git add

but then I have to save all modified files manually to make them appear as unstaged changes

Resharper modifies and writes the files to disk. You don't need to save anything manually. What your describing sounds like a behavior of your IDE or the git plugin for your IDE.

@sethreno sethreno added the wontfix This will not be worked on label Mar 19, 2022
@benrobot
Copy link

It's not so bad if used with --format-only. Formatting and re-staging on-the-fly is a common practice in the JavaScript world. I suppose one could say that the Prettier and ESLint are more mature than ReSharper.

I believe this feature request has a lot of value (I would definitely use it with --format-only) because it speeds up development. Many times I'm happy to let the tools enforce formatting styles chosen by the team on-the-fly.

A useful feature would be a new flag such as --format-or-fail-on-diff that would:

  1. Format files (equivalent to --format-only)
  2. Fail on differences that didn't fall under the --format-only category
  3. Re-stage (if did NOT fail on step 2)

This way the stray newline or missing newline at the end of the file just get fixed but more substantial changes like renaming a variable still stops the commit.

I have experienced multiple teams across multiple repos use a similar commit workflow in the JavaScript world (implemented with ESLint and Husky).

@sethreno sethreno reopened this Apr 23, 2022
@sethreno sethreno added enhancement New feature or request and removed wontfix This will not be worked on labels Apr 23, 2022
@sethreno
Copy link
Owner

@benrobot Thanks for chiming in. On occasion resharper will get confused when a dependency fails to build resulting in using statements incorrectly getting removed. That was my first thought when this idea was mentioned. I think --format-only addresses that.

No surprise that risky behavior is acceptable in the js world though. Auto formatting on commit is probably no riskier than running npm update. 😆

@sethreno sethreno added the help wanted Extra attention is needed label Dec 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants