When staging lines and the `lint-staged` hook is used, the entire file is commited
See original GitHub issueDescription
Instead of commiting the staged lines, GitHub Desktop seems to commit the entire file
Version
GitHub Desktop version: 0.5.8 OS version: macOS 10.12.5 (Sierra)
Steps to Reproduce
- Stage a few lines in a file
- Write your commit message
- Commit
Expected behaviour: Only the selected lines should be commited Actual behaviour: The entire file gets commited Reproduces how often: Always
Logs
2017-05-30T18:39:45.831Z - info: Stats reported.
Additional Information
Might not be useful here, but I should mention that the same thing seems to be happening in the new Atom Git Integration
Issue Analytics
- State:
- Created 6 years ago
- Comments:26 (11 by maintainers)
Top Results From Across the Web
Linting Staged Git Files with lint-staged -- newline - Fullstack.io
With lint-staged , executing the command git commit automatically runs the linter against files staged for commit.
Read more >Using lint-staged, husky, and pre-commit hooks to fail fast and ...
Pre-commit checks run after staging your changes and running git commit and before a commit is completed. If the checks fail then the...
Read more >Diving into Husky and Lint-staged | Laurie on Tech
This means files you've changed or created but haven't yet committed to your project. Working on staged files limits the number of files...
Read more >lint-staged: Lint Your Staged Files | Karuppiah's Blog
This is where lint-staged tool comes into the picture. Usually one would run the code quality check on the whole project in the...
Read more >Run eslint "ONLY" on the staged files - Stack Overflow
With husky v7/lint-staged v11.2.0 - the staged files will simply by added onto the end of your command, separated by spaces.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thinking about this more, I’m betting GitKraken and Sourcetree both use libgit2, in which case they build in hook support themselves. This means that their hook support won’t quite match git’s.
In this case, that happens to work the desired way. But it doesn’t match how git itself behaves, which I’d argue is the standard. So I think this is a won’t fix.
If we find that git itself also behaves how GitKraken and Sourcetree do, we can revisit this.
Interesting! I’ll change the title of this issue then.