So I am trying to configure the CS-fixer as a hook to a git project. It will perform a dry-run in the pre-commit and if there are files with wrong CS it will cancel the commit allowing the dev to perform the correction using the actual fix command.
The issue is that when I switch branches CS-fixer start thinking that the CS of the files are wrong again, but they are not. So when I perform another dry run it will list all the files of the project. If Iask it to correct this files, it will touch all the files and GIT will see them as modified. However, if I try to commit GIT will say nothing to commit.
Use Case (has nothing to deal with the hook itself):
git checkout -b ...); php vendor/friendsofphp/php-cs-fixer/php-cs-fixer fix app/)php vendor/friendsofphp/php-cs-fixer/php-cs-fixer fix app/ --dry-run)Here, all the files will be listed as wrong CS.
git status)Here GIT will see all the files as touched
Finally, GIT will say "Nothing to commit". All the files will remain listed as touched for git status.
In this case the branches I am using are one with the CS correctede by CS-fixer and one that didnt have the code adjusted. I am using PHP 7.0.8 and PHP-CS-FIXER 2.1.2, on a Windows 10 machine. I tryed to delete the cache file after switching branches to check if it was related to th problem.
Hi,
Do you know what changes there are according to Git?
You can also add --diff to the fix command (together with the --dry-run), that way you can see what the fixer would change if you would drop the dry-run flag.
I think this behavior might be because of fixing line ending to Unix style on you Windows machine, but having Git configured to ignore such changes. So when swapping branches the line styles are set back to Windows (\r\n) and than fixed to Unix (\n), etc. But that is just me guessing. We need to know what changes Git list to be sure.
Thought about the line ending issue, but didnt check yet.
Dropped by the --diff flag (dummy file/project I created to test):
Loaded config default.
Using cache file ".php_cs.cache".
1) \index.php
---------- begin diff ----------
--- Original
+++ New
@@ @@
#Warning: Strings contain different line endings!
<?php
/**
*
*/
class ClassName extends AnotherClass
{
public function __construct($argument)
{
# code...
}
}
----------- end diff -----------
Checked all files in 0.031 seconds, 8.000 MB memory used
If I run git diff nothing shows up.
I will check the line endings, if you have any other glue let me know.
Warning: Strings contain different line endings!
looks like a clear hint :)
Didn't see that haha! So is there a way to prevent cs-fixer of checking line ends? Or another work around that allows me to keep working in my Windows/GIT env?
I need the line ends to be changed, cause the production server is a Linux.
Didn't see that haha! So is there a way to prevent cs-fixer of checking line ends?
Yes, you can do two things:
->setLineEnding(line_ending rule, which is likely doing most of the changesAnother way would be to configure git to ignore the line endings and replace those with Linux line endings on commit. Typically this can be done using a gitattributes in the repo; https://help.github.com/articles/dealing-with-line-endings/ Others might be able help you better with that as I haven't worked on Windows for a long time.
you have git setting that tries to normalize line endings for you, that's why even if the fixer changed line ending git shows you no changes.
I would strongly advise you to disallow git to manage line endings.
Hey, just got time now. I am actually going for the --rules=-line_ending option, just tested and it is good to go. I think I need GIT (or something...) dealing with the line endings cause I want everything working in both Windows and Linux. I checked the docs and let GIT make the change for me is an option. Also, not going to dig into it here, out of scope. Maybe later I look for a better way to deal with the line endings. Thank you @SpacePossum, very helpful.
FYI: all modern IDEs on Windows works well with Unix line ending.
Closing due to discussion
good to hear @diegopso :)
Most helpful comment
Hey, just got time now. I am actually going for the
--rules=-line_endingoption, just tested and it is good to go. I think I need GIT (or something...) dealing with the line endings cause I want everything working in both Windows and Linux. I checked the docs and let GIT make the change for me is an option. Also, not going to dig into it here, out of scope. Maybe later I look for a better way to deal with the line endings. Thank you @SpacePossum, very helpful.