And it's actually a lot worse now.įYI what people say about WSL2 having slow IO with windows file system while true is irrelevant. ![]() ![]() Just tried GitHub desktop again coz I miss it and haven't been able to use it since I moved to WSlv2. You'd think WSL support would be a thing by now its more than a year since it was getting adopted by a LOT of people. I hope this extra information comes useful for anyone. Casually, I've also found cloning on Windows (so including GitHub Desktop) always sets core.fileMode to false on the repository. However, I've run the same git rebase tests with both core.fileMode values when repository is normally cloned on Windows from the remote (so not coming from WSL), and, even when ls never shows the executable bits, they never get removed internally from Git when squashing commits involving executable files. The only problem having core.fileMode disabled causes, is it increases the likelyhood of performing a rebase (for these people that are used to it) inadvertedly of the executable bit/s being completely lost internally, because when the setting is true, you can't perform a git rebase since git status shows changes on the working directory due to the "normal" executable bit loss issue, so you would require some effort by executing git restore to clean the working directory ( git reset -hard doesn't work in this case), rather than instinctively switching to WSL and rebasing from there, where the executable bit won't be affected. The change detection (either happening or not) should be matching in GitHub Desktop.Īlso, I did some tests to check how my suggested setup can affect loosing the executable bit upon a git rebase from Windows (Git Bash): it turns out that independently of the applied core.fileMode value, squashing (unifying) commits where a file with executable bit/s is involved always removes these bits not just in the working directory, also in the internal Git index, so if you git push -f from that terminal, the bit will be definitely gone in the remote. To reproduce the issue (or test my solution), you need to ensure that you have a file committed with executable bit (double check with with an ls on WSL and ensure it's committed via git status), then see what happens when you run git status on Git Bash. Note the "false" changes are also reported when running a simple git diff on Windows Git, so I don't think this is really a Desktop Not that I can think of. The default is true (when core.filemode is not specified in the config file).`Īfter this, I no longer see changes caused by filemode changes done in WSL at GitHub Desktop. In such a case it may be necessary to set this variable to false. exporting ext4 via CIFS mount, visiting a Cygwin created repository with Git for Windows or Eclipse). According to the docs:Ī repository, however, may be on a filesystem that handles the filemode correctly, and this variable is set to true when created, but later may be made accessible from another environment that loses the filemode (e.g. On WSL terminal: git config -global core.fileMode true.Īlso, in case you didn't have this setting when cloning repositories on WSL, you need to disable explicitly it per repository:. ![]() On Windows, using Git Bash for instance: git config -global core.fileMode false.GitHub Desktop shows files as changed and wants them to be checked in. GitHub Desktop should show that nothing has actually changed. Running " git status" on the WSL commandline will show that actually nothing has changed. The error: GitHub Desktop will show all scripts as "Changed files", even though nothing was actually changed.Open GitHub Desktop, and add the repo as a local repo.Ensure the files have the 0755 mode, aka "rwxr-xr-x" and that this is the mode of the file on GitHub in the rep. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |