Only need to run lint before push.

[gouri-panda]

Now lint is running every commit. It will be much easier to run lint if it runs only before the push.

[Frans-Lukas]

imo, we want every commit to be runnable and without errors. If the lint is run before pushing instead of before committing we have two options. Make a commit that fixes the potential issues, or revert commits to fix them. The first is bad because it means the previous commits have warnings and maybe even errors in them, and the second option is bad because it is potentially a lot more work than just running the lint before each commit.

What you can do if you really do not want to run the lint for a specific commit (it's tiny, you are 100% certain there are no errors, or it's a temporary commit) is to do the commit with the --no-verify flag. This will skip the lint check but is not recommended.

[macgills]

@Frans-Lukas commits are not necessarily on the repo though. I can't speak to others style of writing but I would nearly always commit and push at the same time so logistically this makes zero difference to me.

If a person has a bunch of local commits, tries to push and then it fails they can happily rebase and rework their local history before making it the history of the repo.

@gouri-panda it might help if you tell us about your workflow.

[gouri-panda]

When I work on an issue. I generally commit small meaningful changes, after the issue is solved i push to my repo.

[macgills]

I am happy for this ticket to be accepted, it will have to delete the commit hook as part of the install task. The install task is located in git-hooks.gradle, This isn't a priority for me right now so I won't get to it for a while but happy for someone else to pick it up

[gouri-panda]

@macgills This issue will be irrelevant after #2360. Should we close this issue?

[macgills]

This changes the behaviour, the documentation does not make this irrelevant

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

[kelson42]

@gouri-panda After 3 years, I finnaly fully read this issue and the comments. I fully agree with @Frans-Lukas. The multiples commits of a PR are not try an errors, they are a way to split an enhancement in multiple logicial small parts. Each part should be linted for quality reasons.

[gouri-panda]

@kelson42 Yup! Couldn’t agree more. At that time I didn't know the value of each commits with lint checks. It's a trade-off between time & efficiency. But in a long run, we can see significant benefits from it!