Closed yannhodiesne closed 2 years ago
Thanks for this PR. I'm not a Fork user myself, so I haven't fully tested it. I added a small comment above, but with that resolved, I think it looks good.
@carlolars What do you think? Could you maybe test/review this PR?
Hi!
Sorry for my very late response. I've tested this change both with and without a space in the path to Fork and it works for me using WSL2 👍
Thanks for the reviews, I applied the fix for the sed call to accommodate for build
/Build
I also got news from the Fork team, they told me the call to the Fork.RI script is inside of the cross-platform code base, so they are not sure how they should escape spaces properly for now, but they kept it inside their backlog
Great, I merged your changes into the development branch, so they will be in the next release. Thanks again for your PR.
While investigating around issue #124, I found out a lot of errors were thrown out of the Fork.RI script:
uname -a
does not contain the WSL build version anymore, making the current check for build 17046 or greater fail with a syntax error because of the format of the regexC:\PROGRA~1
instead ofC:\Program Files
to avoid spaces), theFORK_RI_EXE_PATH
could contain invalid paths as the short name translatesPROGRA~1
toProgram/ Files
, even inside a WSL environmentAs such, this PR contains several changes, each one in its own commit:
cmd.exe
to retrieve the build version consistently (should work with WSL1 too)Several downsides can be noted:
As-is, this PR enables the usage of Fork's interactive rebase tool by manually editing
%localappdata%/Fork/settings.json
to change"GitInstancePath": "C:\\Users\\Surname Lastname\\wslgit\\bin\\git.exe",
to"GitInstancePath": "C:\\Users\\SURNAM~1\\wslgit\\bin\\git.exe",
(confirmed with the author of #124)I'm planning on sending a support request to Fork's maintainers to ask them if it could support spaces in Fork.RI's path, enabling wslgit to work under all setups