Add an option to omit Vim from the installation

[bgshacklett]

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

Summary

Each time I install Git on Windows, I must delete the vim.exe file from under the Git folder to ensure that my preferred Vim distribution is used instead. It would be helpful to be able to omit Vim from the installation in cases where it's already installed on the system.

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

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

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

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.17115.1]
(c) 2017 Microsoft Corporation. All rights reserved.

• 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: VIM
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: WinSSL
CRLF Option: LFOnly
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled

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

n/a

Details

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

ConEmu + PowerShell

• 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.

cd $myGitRepo
Set-Content temp.txt 'foo'
git add .
git commit

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

My preferred Vim distribution should open with the commit message template

• What actually happened instead?

The bundled Vim distribution opens with the commit message template.

** insert URL here **
n/a

[dscho]

Do you know about a way to detect that your preferred Vim is installed, that we could turn into a programmatic check in the installer?

[bgshacklett]

I'll see what I can come up with.

[chrisbra]

Perhaps check your $PATH if Vim/gvim is available? However note, that whatever existing Vim you want to use, it needs to understand the path separators, because an existing Vim might not understand cygwin like paths. One could use cygpath to convert the paths but that might get nasty pretty quickly.

[dscho]

However note, that whatever existing Vim you want to use, it needs to understand the path separators, because an existing Vim might not understand cygwin like paths. One could use cygpath to convert the paths but that might get nasty pretty quickly.

When Git (itself not a Cygwin executable) launches an editor (or for that matter, any other process), the PATH variable is already in Windows format, with semicolons as separators.

So your concern is already addressed (actually, it had been addressed for the entire lifetime of Git for Windows).

I'll see what I can come up with.

@bgshacklett great! FWIW I would not really want to follow this advice:

Perhaps check your $PATH if Vim/gvim is available?

... as that vim executable may very well be from an existing Git for Windows installation (that we will uninstall in the process of upgrading). In that case, we would think that there is a Vim distribution and hand off to that, except it is not a Vim distribution, but our own vim.exe (that we would then probably even delete).

[bbolli]

FWIW, the official VIM Windows installer creates a registry entry unter HKLM\SOFTWARE\Vim\Gvim\path (REG_SZ) pointing to the installed gvim.exe.

[DominikJaniec]

Detection of Vim and skip its installation automatically would be very neat feature, but for me it could be just simple checkbox.

As I can opt-out Git LSF or Windows integration at first configuration page of instalator, I could just do it for Vim - but here I'm assuming that this "toggle" could be passed via execution parameters as other components, couldn't it be?

[dscho]

Detection of Vim and skip its installation automatically would be very neat feature, but for me it could be just simple checkbox.

Sure. And for many others, it should be as descriptive an option as our current options for Git's default editor.

I imagine once @bgshacklett is done, the existing vim option will state that this is the one included in Git for Windows, and there will be another option for Official Vim that describes a bit more, with links and stuff.

As I can opt-out Git LSF or Windows integration at first configuration page of instalator, I could just do it for Vim - but here I'm assuming that this "toggle" could be passed via execution parameters as other components, couldn't it be?

Yes, both components and options can be passed via command-line parameters. The components via InnoSetup's own /COMPONENTS option, the other options via custom options such as /o:EditorOption=VisualStudioCode (this feature has so far only been explained in this commit and not on our wiki, if you are interested in this feature, it would be really nice if you could contribute a new wiki page about this, I can answer any questions you have about the feature).

[bgshacklett]

After spending some time thinking about this, I wonder if the "Choose the default editor used by Git" page could just have an option to browse for an editor at a custom path. It would remove any question as to which editor is being chosen, as well as preventing potential errors in automatic detection logic. It would also have the benefit of allowing the user to choose whatever editor they desire (Sublime, Atom, VS Code, etc.)

[dscho]

After spending some time thinking about this, I wonder if the "Choose the default editor used by Git" page could just have an option to browse for an editor at a custom path. It would remove any question as to which editor is being chosen, as well as preventing potential errors in automatic detection logic. It would also have the benefit of allowing the user to choose whatever editor they desire (Sublime, Atom, VS Code, etc.)

That idea sounds compelling until you think of these two things:

1. Somebody has to not only think about it but do it. And you did not seem to be eager to do anything about it, otherwise you would have opened a PR instead of adding a comment. (Lucky for you, while this behavior is common, there are exceptions).
2. Many editors on Windows return immediately after being called. That is a behavior with which Git cannot work: it relies on the command to return with success after the user is done editing the message. Many editors offer this an optional behavior; VS Code, for example, requires the --wait option to accommodate Git's needs. And you are probably not willing to volunteer for the job answering the tickets that will be invariably opened because "my editor does not work"?

[dscho]

I wonder if the "Choose the default editor used by Git" page could just have an option to browse for an editor at a custom path.

While you were wondering, lucky you, @ungps was not satisfied with only wondering about it but went ahead and implemented this.

[dscho]

For the record, I hid some off-topic remarks and blocked the account responsible for them, as they violate the https://github.com/git-for-windows/git/blob/master/CODE_OF_CONDUCT.md, in particular Our Standards.