Feature/git for windows msi #113
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fourpastmidnight
force-pushed
the
feature/GitForWindowsMSI
branch
from
696af95 to
04006e5
Compare
| -o $TARGET -ext WixUtilExtension -ext WixTagExtension \ | ||
| -ext WixUIExtension -loc GitUI_en-us.wxl \ | ||
| -cultures:en-us \ | ||
| -v \ |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
fourpastmidnight
force-pushed
the
feature/GitForWindowsMSI
branch
from
61289b6 to
c3eb1e7
Compare
| -o $TARGET -ext WixUtilExtension -ext WixTagExtension \ | ||
| -ext WixUIExtension -loc GitUI_en-us.wxl \ | ||
| -cultures:en-us \ | ||
| -spdb \ |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
fourpastmidnight
force-pushed
the
feature/GitForWindowsMSI
branch
5 times, most recently
from
70b944c to
185aada
Compare
| *) | ||
| die "Unhandled architecture: $ARCH" | ||
| ;; | ||
| exit 1 |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
fourpastmidnight
force-pushed
the
feature/GitForWindowsMSI
branch
2 times, most recently
from
7a2c7dc to
791762b
Compare
fourpastmidnight
force-pushed
the
feature/GitForWindowsMSI
branch
from
2b60660 to
f23047f
Compare
| @@ -266,6 +266,8 @@ | |||
| <Fragment> | |||
| <SetProperty Id="ExecConfigureCoreAutoCrlf" Value='"[#GitExe]" config -f "[#GfwGitConfig]" core.autocrlf [LINEENDINGS]' Sequence="execute" Before="ExecConfigureCoreAutoCrlf" /> | |||
| <CustomAction Id="ExecConfigureCoreAutoCrlf" BinaryKey="WixCA" DllEntry="WixQuietExec$(var.SixtyFourBit)" Execute="deferred" Return="ignore" Impersonate="no" /> | |||
| <SetProperty Id="ExecConfigureSslCAInfo" Value='"[#BashExe]" -c "git config -f /c/ProgramData/Git/config http.sslCAinfo \"/[#ca_bundle.crt]\""' Sequence="execute" Before="ExecConfigureSslCAInfo" /> | |||
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
fourpastmidnight
force-pushed
the
feature/GitForWindowsMSI
branch
5 times, most recently
from
10fc862 to
10a97de
Compare
| echo | ||
| echo " where M.m.r.b is the Major, minor, revision, and build number, " | ||
| echo " respectively." | ||
| echo |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This commit rearranges and organizes a few elements in the GitProduct.wxs file. I like to group overall Installer-level elements directly under the <Product /> element. The installer icon is part of this group, as it's usually a "global, shared resource" within the MSI. I follow this initial set of elements with the `ARP*` property declarations and/or `SetProperty` custom actions (these properties contain information displayed by the Add/Remove Programs a/k/a Programs and Features Windows Control Panel applet). These properties are then followed with any `MSI*` properties. After the `ARP*` and `MSI*` properties, product-specific properties are declared (in this case, properties that directly support the logic used to install Git for Windows). This commit doesn't add any Git for Windows specific properties, however. In my experience, ordering the main WiX installer file in this way allows you to quickly find a property declaration and/or installer-specific information instead of it being scattered here and there throughout the file. Signed-off-by: Craig E. Shea <[email protected]>
Often times in WiX, you can specify a condition that governs whether some action occurs (or not) during execution of an MSI. Usually, these condition statements appear as the inner text of an XML element. While you can use XML entity references for conditions such as "not equal" (`<>`), it's much easier to read these conditions if they are placed inside of a CDATA section instead -- especially if the conditional statement is complex. Signed-off-by: Craig E. Shea <[email protected]>
Since the custom action to run `post-install.bat` will not run if the user is completely removing Git for Windows from their system, there's no need to set the property that sets the command to be run to execute the batch file. This commit adds a condition to not execute this custom action on removal to reduce the amount of time it takes to remove Git for Windows from the system. (NOTE: Git for Windows will be removed from the system on upgrades, so this mode will run more frequently than just the case where the user is explicitly uninstalling Git for Windows.) Lastly, collapsed the definition of the custom action to execute the `post-install.bat` file to one line. Signed-off-by: Craig E. Shea <[email protected]>
Software "tagging" is an international standard: ISO/IEC 19770-2. Some large(r) organizations want a way to be able to "inventory" their computer systems to determine what's installed, what version, etc. Since Git for Windows is an extremely popular piece of software that is installed on thousands (millions?) of computers around the world by developers in organizations large and small, we can be good corporate citizens in helping organizations manage what's installed on their computers, allowing them to detect out of date versions and even automate deployments. Since WiX has a very simple way to achieve this, I added the relevant XML namespace, the software tag element in GitProduct.wxs, and referenced the WiX library implementing this standard in release.sh (especially since the library was already available in the wix binaries folder). See http://robmensching.com/blog/posts/2012/4/16/wix-toolset-support-for-software-id-tagging---isoiec-19770-2/ for more information. Signed-off-by: Craig E. Shea <[email protected]>
This commit updates where installation settings are stored in the Windows Registry. The InnoSetup installer currently stores this information in `HKLM\SOFTWARE\GitForWindows`. This commit updates the MSI to store installation settings there, too. Signed-off-by: Craig E. Shea <[email protected]>
Add a `CurrentVersion` registry value entry to `HKLM\SOFTWARE\GitForWindows` so that 3rd party softwares can determine what version of Git for Windows is installed on the machine. Signed-off-by: Craig E. Shea <[email protected]>
Move the GPL RTF license file from the InnoSetup `installer` directory to the top-level `build-extra` directory since it is a "shared resource" that will be used by both the InnoSetup and MSI installers. Signed-off-by: Craig E. Shea <[email protected]>
I ran the wix update script to update the wix toolset, mainly to get the WixUIExtension.dll library containing the stock MSI dialogs that we can reuse. Signed-off-by: Craig E. Shea <[email protected]>
This commit adds the Git for Windows MSI Setup Wizard UI. Adds a reference
to the WixUIExtension.dll in `release.sh` when compiling and linking the
MSI so that the MSI can be built. Some notes:
1. The Git dialogs' control events need to be updated to properly handle
various installation scenarios: repair/reinstall/upgrade.
2. Determine how to handle previous installations of Git for Windows which
used the InnoSetup installer.
* Need to look into whether or not a WiX custom action can be used
which can run an executable to run the InnoSetup uninstaller.
* Barring the option above, message the user "Sorry, you need to
uninstall your previous installation of Git for Windows before you can
install this update." (of course, it should be nicer)
3. There is a note in release.sh (not part of this commit) about "custom"
installers, i.e. people who download the Git for Windows source code/SDK
and create their own custom installation of Git for Windows with custom
packages included (e.g. Emacs instead of Vim or something). We don't want
"hijacked" and/or broken installs--whether intentional or unintentional.
4. I want to customize the setup wizard graphics--but for now, the stock
graphics will do. We just need a working installer.
5. Even though all the custom Git dialogs are wired up and the registry
values for the user's chosen options are being written, the installer
isn't actually configuring anything based off the user's choices. This
still needs to be implemented.
Signed-off-by: Craig E. Shea <[email protected]>
Replaced all the text in the custom Git MSI dialogs with WiX localization variables and updated the GitUI_en-us.wxl localization file with the new localization variables for the custom Git MSI dialogs. Signed-off-by: Craig E. Shea <[email protected]>
The InnoSetup installer installs a copy of `compat-bash.exe` as both `bash.exe` and `sh.exe` in the top-level `INSTALLDIR\bin` folder. Currently, the MSI installer was only installing `compat-bash.exe` as `bash.exe`. Also, `compat-bash.exe` was always sourced from the 'mingw64` folder. On 32-bit architectures, however, `compat-bash.exe` should be sourced from the `mingw32` folder. This commit sources `compat-bash.exe` from the correct architecture for `bash.exe`. I also formatted the `<File />` element so that it occupies only one line. Previously, the MSI was not copying `compat-bash.exe` as `sh.exe` in the `INSTALLFOLDER\bin`. This commit fixes that oversight and also ensures `compat-bash.exe` is sourced from the correct folder based on the architecture the MSI is being built for. Signed-off-by: Craig E. Shea <[email protected]>
The original InnoSetup installer removes the Git configuration setting pack.packsizelimit from the system-wide configuration file iff. it's set to 2g on x64 systems. The MSI now also removes this limit on x64 installs. Signed-off-by: Craig E. Shea <[email protected]>
This commit ensures the MSI will configure the http.sslCAInfo git configuration setting to the proper location of the SSL CA certificates, which up until now, it hasn't been doing. Signed-off-by: Craig E. Shea <[email protected]>
The MSI installer now respects the users' chosen `core.autocrlf` setting during installation and configures it in the git system configuration file for MSYS2. The setting will be appropriately configured whether the installation is performed as a full UI install, or a reduced UI or silent installation. The setting is appropriately configured during repair as well. When this setting is applied on the command line, the values are accepted case-insensitively. This is also important because the user _could_ manually change the registry value for this option, changing the casing, which would then break an upgrade installation. (Property values are case- sensitive, especially when they are used to back a Radio Button group, such as this option. So the installer translates the value of LINEENDINGS to the appropriate casing so that the UI can display the chosen option correctly.) This property follows the Remember Property pattern while allowing a default value to exist for the option. More information about the Remember Property pattern can be found at [Rob Mensching's blog](http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/). The main difference is that instead of saving any command line value received for the property, the command line value is saved only if it differs from the default value. The Remember Property pattern, as written, assumes the property does not have a (default) value (which means that it would not be authored into the MSI Property table). Since this property has a default value, if a command line value is not provided, the property will retain it's authored value and be saved as if it had been provided on the command line. Then, if the user is upgrading, the registry is searched for the property value. If the installed value differs from the default, the property value is updated. But later, the saved "command line" value is "restored" (which wasn't really a command line value, but the property default value), effectively disregarding the user's prior installation setting. By only saving the command line value if it differs from the default, this limitation of the default implementation of the Remember Property pattern is overcome. Signed-off-by: Craig E. Shea <[email protected]>
The MSI installer now respects the user's `core.fscache` setting during installation and configures it in the system git configuration file for MSYS2. The setting is also recorded in the HKLM\SOFTWARE\GitForWindows registry key as a string value to support upgrade scenarios. This setting will be appropriately set whether the installation is performed during a full UI install, or a reduced UI or silent installation. The setting is appropriately configured during repair as well. Since git configuration options are case-insensitive, and git Boolean configuration settings can also be set with a 0 or 1 value, the installer takes care to ensure that it recognizes true and false case-insensitively and also handles 0 or 1 appropriately. Inavlid values, however, will result in the default value being used for all installation types, which is `true`. This property follows the Remember Property pattern while allowing a default value to exist for the option. More information about the Remember Property pattern can be found at [Rob Mensching's blog](http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/). The main difference is that instead of saving any command line value received for the property, the command line value is saved only if it differs from the default value. The Remember Property pattern, as written, assumes the property does not have a (default) value (which means that it would not be authored into the MSI Property table). Since this property has a default value, if a command line value is not provided, the property will retain it's authored value and be saved as if it had been provided on the command line. Then, if the user is upgrading, the registry is searched for the property value. If the installed value differs from the default, the property value is updated. But later, the saved "command line" value is "restored" (which wasn't really a command line value, but the property default value), effectively disregarding the user's prior installation setting. By only saving the command line value if it differs from the default, this limitation of the default implementation of the Remember Property pattern is overcome. You will notice that for Full UI intsalls (UILevel = 5) that if the user has chosen to not enable this property from a previous installation or on the command line, that the property will be set to NULL (`{}`). This is because MSI checkboxes behave very much like HTML checkboxes in that if there is any value whatsoever for the property backing the checkbox, the checkbox will appear checked, even if the value specified for the property is to disable the configuration of the feature. At best, this is confusing for the user and it appears the installer may be broken or not respecting their command line or previous installation choice. They would uncheck the box which would result in the property effectively getting set to NULL. At worst, during the UI install, the checkbox appears checked even though the user chose to disable the option, but they "change their mind" without ever changing the state of the checkbox. Therefore, the property retains its original value (false) and the feature is not configured even though the UI indicated otherwise. Setting the property to null, then, solves this problem. Signed-off-by: Craig E. Shea <[email protected]>
The MSI installer now respects the users's choice of whether or not to enable the Git Credentials Manager for Windows during installaion and configures it in the system git configuration file for MSYS2. The setting is also recorded in the HKLM\SOFTWARE\GitForWindows registry key as a DWORD value to support upgrade scenarios. The setting will be appropriately configured whether the installation is performed during a full UI install or a reduced UI or silent installation. The setting is appropriately configured during repair as well. When specifying this setting on the command line, MSI will accept case-insensitive values of "true" and "false" as well as 0 or 1. This setting is enabled by default if the .NET Framework 4.5.1 or above is installed. This property follows the Remember Property pattern while allowing a default value to exist for the option. More information about the Remember Property pattern can be found at [Rob Mensching's blog](http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/). The main difference is that instead of saving any command line value received for the property, the command line value is saved only if it differs from the default value. The Remember Property pattern, as written, assumes the property does not have a (default) value (which means that it would not be authored into the MSI Property table). Since this property has a default value, if a command line value is not provided, the property will retain it's authored value and be saved as if it had been provided on the command line. Then, if the user is upgrading, the registry is searched for the property value. If the installed value differs from the default, the property value is updated. But later, the saved "command line" value is "restored" (which wasn't really a command line value, but the property default value), effectively disregarding the user's prior installation setting. By only saving the command line value if it differs from the default, this limitation of the default implementation of the Remember Property pattern is overcome. The configuration of this setting is a bit tricky due to some idiosyncracies of MSI. 1. As stated above, the default value for the ENABLEGCM property is 1. 2. If the user passes 0 or "false" on the command line for this option, this value must be saved to another property, for as the installation progresses, ENABLEGCM may change its value, and the user's command line choice should carry all the way through to the UI (if they're performing a full UI install) where they can still change their mind at the last minute. 3. MSI performs a registry search (to support upgrade and repair scenarios to retrieve previously configured installation settings). If it finds a previous installation setting, it sets ENABLEGCM. However, DWORD's come back as formatted strings, e.g. 0x1 ==> "git-for-windows#1". 4. Iff. a previous installation setting was found, and it came back as "git-for-windows#1", then set ENABLEGCM=1 to enable the feature. 5. Otherwise, if on the command line the user passed "false" or 0 for ENABLEGCM, or a previous installation disabled this feature (i.e. the registry search returned "#0"), then set ENABLEGCM=0. 6. If the .NET Framework 4.5.1 or above is not installed, set ENABLEGCM=0. 7. If the MSI is being run as a full UI intsall (which is the most likely scenario 9 times out of 10), and ENABLEGCM=0, then set the ENABLEGCM property to NULL (denoted by '{}'). 8. During the UI phase of setup when the user can choose to enable/disable the feature, if the checkbox is unchecked, the property is essentially set to NULL. In order to properly record the user's installation choice in the registry, the GitAdditionalOptionsDlg checks to see if ENABLEGCM <> 1, and if it's not, it's explicitly set to 0. In addition, this checkbox is disabled if the .NET Framework 4.5.1 or above is not installed to prevent enabling the feature when it's not appropriate to do so. Why is ENABLEGCM set to NULL in step 7? Because this property is used to drive the state of a checkbox on the GitAdditionalOptionsDlg dialog during a full UI installation. MSI checkboxes behave similarly to HTML checkboxes. If the property backing a checkbox has _any_ value, the checkbox will appear checked in the UI. Only the lack of a value (i.e. null) for a property will cause the checkbox to appear unchecked. At best, this is confusing. The user my have indicated to disable this feature on the command line or chosen not to enable the feature previously. But the checkbox is checked and the user still doesn't want this feature, so they uncheck it and everything's OK. The user just doesn't have a great UX. At worst, the user chose to disable this option at some point, but the checkbox appears checked (because the property has a non-null value). The user decides at the last minute to leave the checkbox checked and enable the feature. The problem is, because the state of the checkbox never changed (i.e. the user didn't uncheck and then recheck it), the value of the property is still 0, and so the feature will not be installed, even though the UI seemed to indicate that it would be. So, after all is said and done, if the user chose to disable the option on the command line, or the property has a value that is not 1, or the .NET Framework 4.5.1 is not installed, this property is set to NULL. Lastly, this commit includes the WiX extension in compilation and linking for detecting the installed state of the various .NET Frameworks. Signed-off-by: Craig E. Shea <[email protected]>
Previously, the MSI installer always appended the
`INSTALLFOLDER\mingw??\bin` folder to the machine's `PATH` environment
variable.
The MSI installer now respects the user's installation option for
modifying the system's `PATH` environment variable.
The setting will be appropriately configured whether the installation is
performed as a full UI install, or a reduced UI or silent installation.
The setting is appropriately configured during repair as well.
When this setting is supplied on the command line, the values are accepted
case-insensitively. (Property values are case sensitive, especially when
they are used to back a Radio Button group, such as this option. So the
installer translates the value of CLIENVIRONMENT to the appropriate casing
so that the UI can display the chosen option correctly.)
NOTE: If the user chooses the option to only use Git from the BASH, the
user's PATH environment variable will not be modified, as the
CLIENVIRONMENTPATHS property that modifies the `PATH` environment
variable will be set to NULL (`{}`).
This property follows the Remember Property pattern while allowing a
default value to exist for the option. More information about the
Remember Property pattern can be found at [Rob Mensching's
blog](http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/).
The main difference is that instead of saving any command line value
received for the property, the command line value is only saved if it
differs from the default value. The Remember Property pattern, as written,
assumes the property does not have a (default) value (which means that it
would not be authored into the MSI Property table). Since this property
has a default value, if a command line value is not provided, the property
will retain it's authored value and be saved as if it had been provided on
the command line. Then, if the user is upgrading, the registry is searched
for the property value. If the installed value differs from the default,
the property value is updated. But later, the saved "command line" value
is "restored" (which wasn't really a command line value, but the property
default value), effectively disregarding the user's prior installation
setting. By only saving the command line value if it differs from the
default, this limitation of the default implementation of the Remember
Property pattern is overcome.
Signed-off-by: Craig E. Shea <[email protected]>
The original InnoSetup installer called into the Windows API BindImageEx function on all executables named `git*.exe` and `compat-bash.exe` to optimize loading of the executable's dependent libraries. MSI has this facility built-in via the BindImage MSI table. This commit adds the `@BindPath` attribute to all `<File />` elements whose `@Source` attribute contains the text `compat-bash.exe`, `bash.exe`, `sh.exe`, or `git*.exe`. Signed-off-by: Craig E. Shea <[email protected]>
Adds the LibexecPath registry entry value to the GitForWindows key under HKLM\SOFTWARE. Other credential managers and 3rd party tools/utilities may make use of this information. Signed-off-by: Craig E. Shea <[email protected]>
This is an initial implementation of associating .git* files with the default text editor. I say "initial" because how the UI is presented for this option may change. And if the UI changes, it may change the implementation. But as a first pass, this works as intended so that the initial MSI will have "feature parity" with the InnoSetup installer. Signed-off-by: Craig E. Shea <[email protected]>
fourpastmidnight
force-pushed
the
feature/GitForWindowsMSI
branch
from
0618c1c to
48d76fa
Compare
|
So, I updated this PR, but the commits look out of order.... They're in the correct order in my local repository (and on my GitHub repository), but not in the list on this PR. 😞 Any ideas? |
|
Thank you so much! |
fourpastmidnight
added a commit
to fourpastmidnight/build-extra
that referenced
this pull request
Jul 18, 2016
Back when PR git-for-windows#113 was merged, a mis-spelled variable name slipped through review. When the user chooses the CLI environment to be used with Git for Windows, if the user choses to only use Bash with Git for Windows, the variable `CLIENVIRONMENTPATHS` should be cleared so that the user's `PATH` system environment variable will not be modified (i.e. Git will not be able to be used from the Windows command prompt). This fix corrects the spelling of the variable to ensure that the user's `PATH` system environment variable will not be modified. Signed-off-by: Craig E. Shea <[email protected]>
fourpastmidnight
added a commit
to fourpastmidnight/build-extra
that referenced
this pull request
Jul 18, 2016
Back when PR git-for-windows#113 was merged, a mis-spelled variable name slipped through review. When the user chooses the CLI environment to be used with Git for Windows, if the user choses to only use Bash with Git for Windows, the variable `CLIENVIRONMENTPATHS` should be cleared so that the user's `PATH` system environment variable will not be modified (i.e. Git will not be able to be used from the Windows command prompt). This fix corrects the spelling of the variable to ensure that the user's `PATH` system environment variable will not be modified. Signed-off-by: Craig E. Shea <[email protected]>
fourpastmidnight
added a commit
to fourpastmidnight/build-extra
that referenced
this pull request
Jul 25, 2016
Back when PR git-for-windows#113 was merged, a mis-spelled variable name slipped through review. When the user chooses the CLI environment to be used with Git for Windows, if the user choses to only use Bash with Git for Windows, the variable `CLIENVIRONMENTPATHS` should be cleared so that the user's `PATH` system environment variable will not be modified (i.e. Git will not be able to be used from the Windows command prompt). This fix corrects the spelling of the variable to ensure that the user's `PATH` system environment variable will not be modified. Signed-off-by: Craig E. Shea <[email protected]>
fourpastmidnight
added a commit
to fourpastmidnight/build-extra
that referenced
this pull request
Jul 25, 2016
Back when PR git-for-windows#113 was merged, a mis-spelled variable name slipped through review. When the user chooses the CLI environment to be used with Git for Windows, if the user choses to only use Bash with Git for Windows, the variable `CLIENVIRONMENTPATHS` should be cleared so that the user's `PATH` system environment variable will not be modified (i.e. Git will not be able to be used from the Windows command prompt). This fix corrects the spelling of the variable to ensure that the user's `PATH` system environment variable will not be modified. Signed-off-by: Craig E. Shea <[email protected]>
fourpastmidnight
added a commit
to fourpastmidnight/build-extra
that referenced
this pull request
Oct 1, 2016
Back when PR git-for-windows#113 was merged, a mis-spelled variable name slipped through review. When the user chooses the CLI environment to be used with Git for Windows, if the user choses to only use Bash with Git for Windows, the variable `CLIENVIRONMENTPATHS` should be cleared so that the user's `PATH` system environment variable will not be modified (i.e. Git will not be able to be used from the Windows command prompt). This fix corrects the spelling of the variable to ensure that the user's `PATH` system environment variable will not be modified. Signed-off-by: Craig E. Shea <[email protected]>
This comment was marked as off-topic.
This comment was marked as off-topic.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here's the long-awaited pull request for git-for-windows/git issue #682.