Installer: Use Visual Studio Code as Git's default editor disables "Next >" button

[zanedp]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

I'm installing the 64 bit version of Git for Windows 2.18.0. Git for Windows 2.17.0 is already installed, but I have had this issue with fresh installs and every version of Git for Windows that supports "Visual Studio Code."

$ git --version --build-options
git version 2.17.0.windows.1
cpu: x86_64
built from commit: e7621d891d081acff6acd1f0ba6ae0adce06dd09
sizeof-long: 4

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Windows 7 Pro, 64 bit.

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VisualStudioCode
Path Option: CmdTools
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

$ which code
/c/Program Files (x86)/Microsoft VS Code/bin/code

$ code --version
1.24.1
24f62626b222e9a8313213fb64b10d741a326288
ia32

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

1. Launch the Git 2.18.0 Setup app

2. Click Next > until arriving on the the Choosing the default editor used by Git step.

3. Choose Use Visual Studio Code as Git's default editor (or Use Visual Studio Code Insiders as Git's default editor). Notice the Next > button becomes disabled and installation cannot continue. (The description of Visual Studio code is also gray, but it's black for all the other editor choices).
   

4. Click < Back to return to the Select Components step.

5. Click Next >, to return to Choosing the default editor used by Git. Notice that Use Visual Studio Code as Git's default editor is still selected, but the Next > button is now enabled and functions.
   

• What did you expect to occur after running these commands?

I expected to be able to click Next > immediately after selecting Use Visual Studio Code as Git's default editor on the Choosing the default editor used by Git step, not having to go back and forth through the wizard.

• What actually happened instead?

I was not able to click Next > to continue installation after selecting Use Visual Studio Code as Git's default editor on the Choosing the default editor used by Git step. Instead, I needed to go backwards and forwards in the wizard before I could continue.

[dscho]

The installer looks for the registry setting HKEY_LOCAL_MACHINE,'SOFTWARE\Classes\Applications\Code.exe\shell\open\command. If it does not exist, the "Visual Studio Code" option is considered invalid.

Can you investigate what is different from this expectation on your machine?

[zanedp]

The only item under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\Code.exe is DefaultIcon with the (Default) value C:\Program Files (x86)\Microsoft VS Code\resources\app\resources\win32\code_file.ico

I do have an Open with Code item on my Windows Explorer context menu when right-clicking on a file, but I cannot find a registry entry containing that text.

[dscho]

Hmm. That's unfortunate. Without a reliable means to detect the presence of VS Code, we cannot go forward. (And looking in the PATH for any random code.exe is not reliable enough...)

[kelvin-mkc]

How about adding an "Other" option, which reveals both a text input and a button
which opens a file selection dialog?

The editable text field would allow easily adding arguments.

Like so:

["path_to_editor"] (Browse)

This would make it easier to use portable/non-installed editors.

It might also be helpful to make the path field always visible and the options
merely change the value of the field, to be able to tweak the command of the
selected editor, but I suppose that would require many more changes in the setup
script.

[dscho]

How about adding an "Other" option, which reveals both a text input and a button
which opens a file selection dialog?

The editable text field would allow easily adding arguments.

Great idea! Now you only need to implement it and open a PR ;-)

Interested? Start by installing the SDK and calling sdk build git-and-installer, then sdk cd build-extra and edit installer/install.iss to your heart's extent (the commit history of that file should be helpful, too).

[kelvin-mkc]

Great idea! Now you only need to implement it and open a PR ;-)

Interested? Start by installing the SDK and calling sdk build git-and-installer, then sdk cd build-extra and edit installer/install.iss to your heart's extent (the commit history of that file should be helpful, too).

Thanks for the encouragement and instructions, I'll give it a try.

[lashchev]

I have the same issue and I am using VS Code in a "portable" mode (downloaded as ZIP and not as an installer). I don't have "Open with Code" and won't have it, because my dev setup for this project is "portable" (on a pen drive, in VHD file to be exact).

Searching via PATH and propose it as VSCode location seems like a pretty good option IMHO.
Ability to pick a different folder/location is nice to have also.

As a workaround I was able to solve this problem by right-clicking on a file where extension was not associated with any app yet and select "Open with... > (point at Code.exe)". After this Git setup found VSCode right away. But actually I don't want associate Code.exe with anything on the setups that I work on, so this is not a long term solution for me (I had to cleanup registry after this).

[dscho]

Searching via PATH and propose it as VSCode location seems like a pretty good option IMHO.

No, because you are using something portable, which by definition can go away very easily and quickly.

For your use case, I would suggest overriding the editor the good old way, manually, by setting core.editor yourself. Because that is the documented way to set Git's default editor (this applies to Git on all platforms, not just Windows).

[dscho]

I'll give it a try.

@kelvin-mkc please do holler whenever you get stuck. I can assist.

[kelvin-mkc]

@dscho Thanks. I had some problems with the sdk a while ago and got around to
fixing them only yesterday (see #1765).

So, I was editing the options on install.iss when I read
lashchev's comment and realized that the portable installer needs something
like this too.

Then I noticed that the portable installer has a root template with /etc and
/usr. And that both the normal and portable installers map /home to
%UserProfile% and /tmp to %TMP%, respectively.

With that, I've been thinking:

To make it really portable, perhaps the portable installer should behave a bit
more like MSYS2. As in binding /home (and possibly /tmp) to the install
location. Something like /home/git.

That way, one could use portable .gitconfig and .bashrc
files, without messing with the ones in the host system. .bashrc alone
seems like it would help a lot, since one could just set any environment
variables in it.

What do you think?

[dscho]

To make it really portable, perhaps the portable installer should behave a bit
more like MSYS2. As in binding /home (and possibly /tmp) to the install
location. Something like /home/git.

This idea has been tossed around, but I am wary: I do not know how many existing users this would break, and with an estimated install base of several million, I have to be very protective: even breaking 0.001% of Git for Windows' users could overwhelm me (as Git for Windows' maintainer) with angry bug reports.

[dfloyd785]

Is there any guidance on this? I don't have that Reg Key in HKLM, but I do have it in HKCU. Any way you can modify the precheck to look in either location? I am on Win10 Pro 64-bit on 1803 Update, FYI.

[shiftkey]

@dfloyd785 this is because VSCode 1.26 now defaults to a user-based install (no elevation required). The Git for Windows installer needs to be updated to look at either location.

cc @ungps who is currently working on git-for-windows/build-extra#200

[mfriedrich74]

Hi, You should be careful with user specific paths, they are usually not accessible by other user accounts. Those paths should go into global configs, not in system configs. Am I correct that the installer adds the selection into the system config? Best regards, Mike

…

On Fri, Aug 17, 2018, 7:16 AM Brendan Forster ***@***.***> wrote: @dfloyd785 <https://github.com/dfloyd785> this is because VSCode 1.26 now defaults to a user-based install (no elevation required). The Git for Windows installer needs to be updated to look at either location. cc @ungps <https://github.com/ungps> who is currently working on git-for-windows/build-extra#200 <git-for-windows/build-extra#200> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1741 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHJ-yEjSS4Ze3iHoSKE3yo9rOxnWJqzlks5uRqXvgaJpZM4U8EdP> .

[dfloyd785]

So I can confirm the problem is sort of a mix of people to blame. Firstly, VS Code defaults the choice of installation to be a user installation, you have to navigate to the downloads page to specify a system install. However, if possible, since this is now the default install method, I feel that you should either provide that as an instruction/warning to users wanting to use VSCode as the editor, or have the precheck query for both locations, and proceed if either returns as true. Or maybe contact the VS Code team and ask them to change the default install. Thanks, Dan Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

________________________________ From: Mike Friedrich <notifications@github.com> Sent: Friday, August 17, 2018 8:19:00 AM To: git-for-windows/git Cc: dfloyd785; Mention Subject: Re: [git-for-windows/git] Installer: Use Visual Studio Code as Git's default editor disables "Next >" button (#1741) Hi, You should be careful with user specific paths, they are usually not accessible by other user accounts. Those paths should go into global configs, not in system configs. Am I correct that the installer adds the selection into the system config? Best regards, Mike

On Fri, Aug 17, 2018, 7:16 AM Brendan Forster ***@***.***> wrote: @dfloyd785 <https://github.com/dfloyd785> this is because VSCode 1.26 now defaults to a user-based install (no elevation required). The Git for Windows installer needs to be updated to look at either location. cc @ungps <https://github.com/ungps> who is currently working on git-for-windows/build-extra#200 <git-for-windows/build-extra#200> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1741 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHJ-yEjSS4Ze3iHoSKE3yo9rOxnWJqzlks5uRqXvgaJpZM4U8EdP> .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1741 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Ab53JC99AY4DQBArOcA4vWsff-8wxOsVks5uRt7kgaJpZM4U8EdP>.

[ungps]

Here:

• Fixed this VSCode is not set as default editor #1795

• Added Sublime and Atom as possible text editors.

• Now installer check both locations in registry. (this fixes the problem where VSCode v1.26 is not detected)

• Added option to select any editor by browsing in the file system.

[dfloyd785]

Awesome, that was fast! Keep up the great work! Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: ungps <notifications@github.com> Sent: Saturday, August 18, 2018 7:08:46 AM To: git-for-windows/git Cc: dfloyd785; Mention Subject: Re: [git-for-windows/git] Installer: Use Visual Studio Code as Git's default editor disables "Next >" button (#1741) Here<git-for-windows/build-extra#200>: * Fixed this #1795<#1795> * Added Sublime and Atom as possible text editors. * Now installer check both locations in registry. * Added option to select any editor by browsing in the file system. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1741 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Ab53JFZPBeydbeHixf40dNCzPfYGkoJ5ks5uSB_ugaJpZM4U8EdP>.

[Kizmar]

I'm trying to install Git 2.19.0 and running in to this. I'm not seeing an option to pick using the file system either.

I'm on vscode version: 1.27.2 (user setup)

[EDIT] The "back" button workaround got me past it though...

[rafalborczuch]

VS Code has ability to be installed in user setup mode. If you have it installed like that:

Version: 1.27.2 (user setup)
Commit: f46c4c469d6e6d8c46f268d1553c5dc4b475840f
Date: 2018-09-12T16:17:45.060Z
Electron: 2.0.7
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64

then the correct registry key to check is:
Computer\HKEY_CURRENT_USER\Software\Classes\Applications\Code.exe\shell\open\command

[anthcool]

To whom this may concern,

I’m trying to update Git itself to version 2.19.0 from 2.18.0.windows.1 using the installer that can be downloaded from https://git-scm.com/downloads, and when I get to the part where I choose the default editor to use, as soon as I go to choose VS Code as the default, or anything other than Vim, the Next button grays out/disables. I’m hearing that this may be due to my having updated VS Code to their new user level install option instead of using the system level install they’ve had up till now. The Github for Desktop team has already updated their installer and things work on that end. The actual Git for Windows installer still doesn’t work in this regard with user-level installs of editors. Can we get this fixed soon? I don't want a workaround, I want the installer to do its job, irrespective of outside integrations. It should be loosely coupled from all those. Thanks!

[dfloyd785]

Is it possible that the fork that became 2.19 doesn't have the precheck for both locations for the reg key? I had no issues with 2.18 with VS Code after change listed in response to my previous email. Get Outlook for Android<https://aka.ms/ghei36> From: @MrAnthCool Sent: Thursday, September 20, 09:29 Subject: Re: [git-for-windows/git] Installer: Use Visual Studio Code as Git's default editor disables "Next >" button (#1741) To: git-for-windows/git Cc: dfloyd785, Mention To whom this may concern, I’m trying to update Git itself to version 2.19.0 from 2.18.0.windows.1 using the installer that can be downloaded from https://git-scm.com/downloads, and when I get to the part where I choose the default editor to use, as soon as I go to choose VS Code as the default, or anything other than Vim, the Next button grays out/disables. I’m hearing that this may be due to my having updated VS Code to their new user level install option instead of using the system level install they’ve had up till now. The Github for Desktop team has already updated their installer and things work on that end. The actual Git for Windows installer still doesn’t work in this regard with user-level installs of editors. Can we get this fixed soon? I don't want a workaround, I want the installer to do its job, irrespective of outside integrations. It should be loosely coupled from all those. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1741 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Ab53JGPKNtBB0l0rq8T3hcDL6QX4NGduks5uc8JbgaJpZM4U8EdP>.

[PhilipOakley]

@MJCD Unfortunately, a very large fraction of Git for Windows users are in 'managed' corporate environments, so they don't get the opportunities that those in free-wheeling environments have. Often they (with their allocated personal user access control UAC limits) simply can't get the appropriate settings.

Plus in the Kruger-Dunning spread there is always a swath of folks who's primary talents and specialisations are elsewhere. One gets complaints either ways (a) not enough buttons, (b) too many buttons, (c) remember my previous settings [and make it still work despite other changes], (d) I want to change my previous/original settings [I didn't realise what I needed at the time], (e) stop hassling me with question pages, (f) [other options available...]

It's tricky, and the big picture is complicated. Hopefully a reasonable solution will be available soon.

[dscho]

It is really sad to read this ticket: so many suggestions how other people should spend their time, and nobody really stepping up as an adult who takes things into their own hands.

As it happens, I am convinced that this has been addressed, by people elsewhere who did that adult thing.

[sentiment-bot]

Please be sure to review the code of conduct and be respectful of other users. cc/ @git-for-windows/trusted-git-for-windows-developers
Keep in mind, this repository uses the Contributor Covenant.

[dscho]

For transparency: the abusive user who was correctly reported by the @sentiment-bot has been blocked.