Lint git index content on commit#113300
Conversation
This fixes two fundamental issues: * the list of files to be linted is built looking at the diffs of the ref specified with `--ref` (or otherwise the current index) with those on the filesystem * the content to be linted is read from the filesystem instead of the specified `ref` or the one in the index
spalger
left a comment
There was a problem hiding this comment.
Thank you!! This is great
… assignable to parameter of type 'never'"
Previously a refs interval was need needed, as leakage of the implementation of precommit_hook.
|
I'm a bit perplexed by this (from commit_check_runner.sh): Is in the plans to actually drop the pre-commit hook usage on dev's machines? To me it looks beneficial and actually useful to intercept as early as possible any gating issue to the PR merging, which is why I tried to improve the status quo. |
Yes, it's actually already done. The precommit hook isn't setup by default when you bootstrap. We found the precommit hook to mostly be annoying and that with good IDE integrations and auto-fix on save it seemed rather unnecessary. Though, like the message reads, users can opt into the precommit hook and have it installed. Additionally, we run the equivalent checks first on CI so that it can tell users as quickly as possible when they do have issues which would have been caught by the precommit hook (had they installed it). |
| const simpleGit = new SimpleGit(REPO_ROOT); | ||
| const gitRefForDiff = gitRef ? gitRef : '--cached'; | ||
| const output = await fcb((cb) => simpleGit.diff(['--name-status', gitRefForDiff], cb)); | ||
| const gitCatPrefix = gitRef ? gitRef + ':' : ':'; |
There was a problem hiding this comment.
Do you think we could use a git command to resolve a git range to the latest sha so that we could pass things like --ref master^^...HEAD and then read the blobs from the sha pointed to by HEAD?
There was a problem hiding this comment.
I can check. I also see the value of specifying a range.
There was a problem hiding this comment.
With that use case in mind, I think that for the --ref usage I should simply revert to the original behavior. Which is, the range is used only to build the list of files. The linting is actually done on the files as-is on disk, effectively locking the right end of the range to HEAD.
Otherwise a given file would be linted as many time as the many commits that change it, possibly reporting problems that would otherwise elide in the whole range.
There was a problem hiding this comment.
Hmmmmmm... I definitely think that we use the --ref more often to lint all the file that changed since a specific ref. I guess I just assumed that this would work that way too but maybe that was a bad assumption. Maybe we need to rename --ref or fix the --help text?
There was a problem hiding this comment.
For instance, with the recent prettier update, we used it to help people --fix all the files that were modified in their PR
There was a problem hiding this comment.
Do you think we could use a git command to resolve a git range to the latest sha so that we could pass things like
--ref master^^...HEADand then read the blobs from the sha pointed to byHEAD?
Forget my previous claims, I implemented this case ;)
|
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
spalger
left a comment
There was a problem hiding this comment.
LGTM, thanks for your help making this better!
This fixes two fundamental issues: * the list of files to be linted is built looking at the diffs of the ref specified with `--ref` (or otherwise the current index) with those on the filesystem * the content to be linted is read from the filesystem instead of the specified `ref` or the one in the index
This fixes two fundamental issues: * the list of files to be linted is built looking at the diffs of the ref specified with `--ref` (or otherwise the current index) with those on the filesystem * the content to be linted is read from the filesystem instead of the specified `ref` or the one in the index
This fixes two fundamental issues: * the list of files to be linted is built looking at the diffs of the ref specified with `--ref` (or otherwise the current index) with those on the filesystem * the content to be linted is read from the filesystem instead of the specified `ref` or the one in the index Co-authored-by: Domenico Andreoli <domenico.andreoli@elastic.co>
This fixes two fundamental issues: * the list of files to be linted is built looking at the diffs of the ref specified with `--ref` (or otherwise the current index) with those on the filesystem * the content to be linted is read from the filesystem instead of the specified `ref` or the one in the index Co-authored-by: Domenico Andreoli <domenico.andreoli@elastic.co>
|
Sorry @cavokz, but it seems that scss linting is broken with this PR. I'm not sure what the issue is, but I'm going to need to revert this for now. |
I'd like to understand what got broken. I tested it with scss files. Do you have a link for me? |
|
I was able to reproduce the issue in #113570, which is admittedly a large reproduction case, but you can reproduce it by trying to run the pre-commit hook on any scss file with |
This was auto-backported to 7.x and 7.15, did you revert it from there as well? |
Sorry, missed this, but yes. Thanks for checking |
This fixes two fundamental issues:
--ref(or otherwise the current index) with those on the filesystem--refor the one in the index