precise-commits: Modifications not being commited

Hi! I just discovered the project and it is exactly what I was looking for 😃 I am coming from lint-staged and I was looking for this extra precision 😃

I just did my first attempt to use it within the precommit hook. I staged some unformatted files and then committed them.

  • What I expected: to get the staged files first formatted and then committed.
  • What happened: I got the staged files committed, then they got formatted and this modifications remained as unstaged.

I guess my expectations are the intended way to work, right? I’m using precise-commits 1.0.0 and husky 0.14.3

Please let me know if you need some extra info or clarifications.

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Reactions: 11
  • Comments: 20 (4 by maintainers)

Commits related to this issue

Most upvoted comments

Why even use a precommit hook when the resulting commit is not affected in any way? This is counter-intuitive.

As for me, I would appreciate an auto-commit flag as well. Thanks for your work!

Hi @CarlosGines, thanks for raising!

Currently your expectation from lint-staged is not the way precise-commits is set up to work. We are still discussing the optimal workflow when it comes to applying the formatting to git. Some feel quite strongly that the logic and version control should be separate, as sometimes “magic” commits happening behind the scenes can be undesirable.

We may end up adding a flag for the auto-commit behaviour, I will update this issue with progress.

@drazik, cool, this seems to be working as desired:

// lint-staged.config.js
module.exports = {
  linters: {
    '*.js': ['precise-commits', 'git add'],
  },
};

For those who came here because lint-staged didn’t handle partially staged files, it’s does it now: https://hackernoon.com/announcing-lint-staged-with-support-for-partially-staged-files-abc24a40d3ff

This is what would work for me:

  1. Automatically re-stage the formatting changes, so that they land with the original commit.
  2. Leave the formatting changes unstaged, but ERROR OUT of the githook, so that I can abort the commit and prompt the user to selectively add the reformatted chunks into his commit and try again. Right now the only way to error out is with the check-only flag, which will not perform the formatting changes at all.

In the meantime, I will have to change to a different tool, but I’d rather use this one.

To prevent “magic” commits, an auto stage flag would also be a nice option. So it would be easier to commit the prettified changes in a next commit.

So, are people always committing twice? Just trying to understand the recommended workflow. Seems like it would be undesirable to always have two commits for each… commit.

“Add Foo to Bar” “Prettier cleanup”

“Add Bar to Baz” “Prettier cleanup”

You could, of course, use a vscode prettier extension but then what’s the point of this library?

in the package.json scripts

"scripts": {
  "precise-commits": "precise-commits",
  "precommit": "npm run precise-commits && lint-staged"
},
"lint-staged": {
  "*.js": ["git add"]
}

this will do what you guys are wanting i think

@vicb is working on this for angular/angular