Update installer/portable/mingit for the new system config location #262
Conversation
This file contains 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
In git-for-windows/git#2358, we adjusted the location of the system config and gitattributes file. This patch adjusts the post-install script of the `git-extra` package (which is used to edit some files that cannot otherwise be overridden in a regular MSYS2 setup) to expect the system config in the new place. Signed-off-by: Johannes Schindelin <[email protected]>
The post-install script of the Git LFS package wants to adjust the system config. Previously, we needed to make sure that this catches both 32-bit and 64-bit locations of the system config. But now we only have one, so we can simplify things quite a bit. Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
The installer gained this neat feature where it retains any settings across upgrades, even those that were configured in the system config by something else than the Git for Windows installer. We already look both in the old and the new location (which was the location in Git for Windows 1.x) when saving a copy, but we now have to use the location reported by Git when restoring it (depending which Git version is about to be bundled in the installer, that is, which might be the new one, `C:\Program Files\Git\etc\gitconfig`). Signed-off-by: Johannes Schindelin <[email protected]>
The system config location just changed, to `/etc/gitconfig`, but we need to be able to override in case that the Git version we include in the installer does not yet have that PR merged. Signed-off-by: Johannes Schindelin <[email protected]>
In git-for-windows/git#2358, we reconciled the two system configs into a single one. Even if we now build an installer bundling a Git executable that is still ProgramData-aware, it does not hurt to already drop bothering about editing/initializing it: the system config in `C:\Program Files` would override the ProgramData one anyway. Note: for the time being, we still initialize the defaults for the settings that can be configured in Git for Windows' installer from _both_ ProgramData _and_ the previous installation's system config. Signed-off-by: Johannes Schindelin <[email protected]>
In git-for-windows/git#2358, we fixed the design where Git for Windows would first read a "public" system config that was not even in `C:\Program Files\Git` and then would read a "private" system config. It now only reads _one_ system config, and that is in an intuitive location: `C:\Program Files\Git\etc\gitconfig`. Let's teach the script that generates the installer to make sure to ask `git.exe` what its idea of the system config location is, and then use that. Signed-off-by: Johannes Schindelin <[email protected]>
In git-for-windows/git#2358, we fixed the design where Git for Windows would first read a "public" system config that was not even in `C:\Program Files\Git` and then would read a "private" system config. It now only reads _one_ system config, and that is in an intuitive location: `C:\Program Files\Git\etc\gitconfig`. Let's teach the script that generates the Portable Git to make sure to ask `git.exe` what its idea of the system config location is, and then use that. Signed-off-by: Johannes Schindelin <[email protected]>
In git-for-windows/git#2358, we fixed the design where Git for Windows would first read a "public" system config that was not even in `C:\Program Files\Git` and then would read a "private" system config. It now only reads _one_ system config, and that is in an intuitive location: `C:\Program Files\Git\etc\gitconfig`. Let's teach the script that generates the MinGit subset of Git for Windows to make sure to ask `git.exe` what its idea of the system config location is, and then use that. Signed-off-by: Johannes Schindelin <[email protected]>
Previously, we shared Git for Windows' config with MinGit-based applications via `C:\ProgramData\Git\config`. However, we just reconciled this config with the "other" system config, so there is no system config outside of the installation anymore. To reinstate the ability of MinGit to reuse the settings configured via Git for Windows' installer (such as `core.autoCRLF`), let's just include the system config of the installed Git for Windows (if any) right at the beginning of MinGit's own system config. For good measure, we first include the system config of a 32-bit Git for Windows that is installed on a 64-bit Windows (which does not make too much sense, but some users still do that), and then include the regular Git for Windows' system config. In addition to hard-coding the `C:\Program Files` part, we also hard-code the path to the new location of the system config (i.e. the one _without_ the `mingw64` part) because the Git for Windows installation will most likely have it long before any new MinGit version meets the users. Note: if `include.path` does not point to an existing file, Git will simply ignore it, without a warning, which is exactly what we want here. Signed-off-by: Johannes Schindelin <[email protected]>
Previously, we already adjusted the location of the system config, now it is time for the system gitattributes. Note: with this change, not the system gitattributes file is included not only in the MinGit version of Git for Windows, but also the BusyBox variant thereof. Signed-off-by: Johannes Schindelin <[email protected]>
Hopefully this will be enough to make people aware, together with a little bit of hollering on the Git mailing list and Twitter... Signed-off-by: Johannes Schindelin <[email protected]>
dscho
requested review from
shiftkey,
PhilipOakley,
ethomson,
landstander668,
fourpastmidnight and
jeffhostetler
|
I merged it because Git v2.24.0 was already released, and now I have to scramble to get Git for Windows v2.24.0 out... |
|
Sorry, don't get chance at a proper viewing before you needed to merge it. I did not see anything to be noted. LGTM. |
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.
This is a follow-up PR for git-for-windows/git#2358, and it will need to be merged before that one, so that the next snapshot won't be broken.
The idea is to prepare the scripts that generate the Git for Windows installer, the Portable Git and the MinGit versions to accommodate for Git versions that have only one system config: Instead of reading
C:\ProgramData\Git\configand thenC:\Program Files\Git\mingw64\etc\gitconfig(or for 32-bit Git on 64-bit Windows,C:\Program Files (x86)\Git\mingw32\etc\gitconfig), we now only read from the quite intuitive locationC:\Program Files\Git\etc\gitconfig, i.e. without themingw64part.This also addresses the issue raised many times that the Portable Git relied on settings configured outside of the Portable Git (
C:\ProgramData\Git\config), in addition to squelching complaints that there is no equivalent to the--systemoption for writing to the ProgramData config.Finally, the ProgramData config was meant to be a truly Windows-wide config, but it lacked buy-in. For example, JGit (which is implicitly used by pretty much every Android Studio/Eclipse user) does not support it. At the same time, libgit2 seems to never have stopped looking for
C:\Program Files\Git\etc\gitconfig. In short: the ProgramData config failed to serve its purpose, anyway.