Repository navigation
Provide installer option to install per-user even if user is admin #4758
Description
Setup
- Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options
git version 2.43.0.windows.1
cpu: x86_64
built from commit: 4b968f3ea3b32a7bc50846bab49f3f381841d297
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
- 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.22631.2861]
- 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"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: ExternalOpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled
- Any other interesting things about your environment that might be related
to the issue you're seeing?
Details
- Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
PowerShell-Core
- 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.
winget install --no-upgrade --scope=user -h --accept-package-agreements --accept-source-agreements Git.Git --custom '"/COMPONENTS=`"icons,assoc,assoc_sh,,,,gitlfs,icons\quicklaunch`" /o:SSHOption=ExternalOpenSSH"'
- What did you expect to occur after running these commands?
I should not see UAC prompt and git should be installed to "$env:USERPROFILE\AppData\Local\Programs\Git", not to "C:\Program Files\Git"
- What actually happened instead?
I see UAC prompt in user scope and git is installed "C:\Program Files\Git" instead of "$env:USERPROFILE\AppData\Local\Programs\Git"
- If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?
** insert URL here **
Activity
soredake commentedon Jan 6, 2024
Related:
#4399 (reply in thread)
microsoft/winget-cli#3240
dscho commentedon Jan 24, 2024
Git for Windows uses InnoSetup to build the installer. There is an option to specify the required privileges,
PrivilegesRequired, which is used by the installer (we even use the undocumentednonevalue which was deprecated a long time ago, in favor oflowest, which would however not work for us because it would no longer allow installing in admin mode).Having said that, I missed that InnoSetup 6.0.0 introduced a new option to allow overriding the install mode:
PrivilegesRequiredOverridesAllowed. This might make it possible to offer a user-wide installation mode.However, it won't be as simple as merely adding that option to the
install.issfile: There are most likely parts of the code that expect to be installed into the system-wide locationC:\Program Files\Gitand that will need to be vetted carefully.fadein commentedon May 11, 2024
@dscho, I went ahead and rebuilt the installer according to your suggestion above... and it just worked. GfW is installed under my user's %AppData% and works beautifully. I have re-installed it many times with various combinations of options but have yet to find a single issue.
The nearest thing to a problem that I have encountered is that the Git Bash shortcut which Windows Explorer "helpfully" creates when you pin the app to the task bar referred to the path
C:\Program Files\Git. This file was made by Windows under the path%AppData%\Roaming\Microsoft\Internet Explorer\QuickLaunch\TemproraryShortcutsand was not removed when I uninstalled GfW (which makes sense because the GfW installer did not create it). After I re-installed GfW to the new path this shortcut still pointed to the old path.I scanned through
build-extra/installer/install.issbut cannot find any hard coded instances ofC:\Program Files. As far as I can tell, this change could be released. Can you tell me some things I could look out for that you are concerned could be broken by this change?As for the patch, I just replaced the entire
#ifdefat lines 81-85 with these two lines:It appeared to me that
#ifdefwas not working as expected, but I don't understand the significance of theOUTPUT_TO_TEMPsymbol.dscho commentedon May 11, 2024
Hmm. @fadein this would most likely be due to some sort of caching, as the information used for pinning refers to
"@@EXEPATH@@\\git-bash.exewhere@@EXEPATH@@gets interpolated to the location ofgit-bash.exe.It would still be nice to remove it, we have a dedicated section for removing such shortcuts in the installer definition.
By the way, this is exactly what I was referring to careful vetting, going through the (admittedly long, almost 4k lines)
install.issfile to see what might need to be adjusted.The
OUTPUT_TO_TEMPconstant is defined inconfig.iss, which is written byrelease.sh.It would probably need to be changed to something like this:
I do wonder, though, whether that incurs a change of behavior for the use case I actually want to support: installing into
C:\Program Files\Git. I could imagine that the proposed change will now add yet another dialog for the user to click through?Besides, there is one rather big fall-out that we would suffer from this change: If we install into
%LOCALAPPDATA%, naturally Git's config will also be located there. That breaks the contract with MinGit, which is shipping with a carefully modified systemgitconfigthat wants to inherit the configuration of the installed Git for Windows, if any:This is crucial because that config contains settings that change Git's behavior, such as
core.autoCRLF,http.sslBackend,filter.lfs.required, etc. If the regular Git for Windows is used to access repositories with these settings, and MinGit (used in 3rd-party applications) would be used without these settings, it could wreak quite a bit of havoc.We could of course extend that
[include]list by appending, say,path = ~/AppData/Local/Programs/Git/etc/gitconfig. That change would then percolate into the next Git for Windows, and more importantly, MinGit release. Which would be eventually picked up by downstream users such as Visual Studio and GitHub Desktop. Once those downstream users have integrated a MinGit version with this change, experience tells us that it will still take quite some time for users of those programs to update. Up until that time, if we were to make that installer change, we would break those setups.There are millions of Visual Studio/GitHub Desktop users out there that would be negatively impacted if we rushed this change in the installer. This fact dictates that we need to tread very wisely here. The best course of action would be to make that MinGit change, verify that it actually works as intended, publish it with Git for Windows v2.46 scheduled for July 29th, 2024, and then wait an appropriate amount of time before integrating that
install.isschange. Or maybe not wait, exactly, but use that time wisely to continue thinking about potentially undesirable consequences of making this change.