[pull] master from git:master - #256
Merged
Merged
Conversation
After the user has selected a color in the Preferences dialog, the helper proc prefspage_set_colorswatches is used to update the colors shown in the Preferences dialog. Use this proc also to show the initial colors after the Preferences dialog is constructed. This keeps the procedure that gives the UI elements their colors in a single place. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
The color selection elements in the Preferences dialog are set up in a very uniform manner. The code doing that has grown in the past by simply modifying a copy of a paragraph. Extract the varying parts into a list and then operate the repeating parts in a foreach loop. This helps a later change where we want to set up the UI elements in a different way. Change the UI names "markbgsep" and "selbgsep" to drop the "sep", which has obviously been left over by accident when "hunksep" was copied. Change the suffix "but" to "btn", which resonates a bit better when reading the code. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
When the user goes to the color preferences, the eye is automatically drawn to the color samples. However, clicking on the sample with the intent to change it does nothing. Instead, the text label also acts as a button and must be clicked to change the color. Turn the color samples into clickable buttons and the text labels into static text. Use non-themed buttons because their color can be changed by simply specifying the color properties. (Themed buttons would need a lot more elaboration.) Signed-off-by: Johannes Sixt <j6t@kdbg.org>
The labels used to be clickable buttons. These would have looked funny if they carried long texts. For this reason, jargon and abbreviations were used to keep them short. Since there is no button frame around the labels anymore, the texts can become longer without becoming ugly. Bring them closer to natural language. Remove the prefix "Diff" from labels, because the remaining texts are sufficiently unambiguous that they are about diff text. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
When the user clicks a color preference, a color selection dialog is presented whose title is provided in parts by the caller. The dialog implementation must supply the rest of the title. This is unfriendly for translations. Provide the full title by the caller. Rewrite the texts to be more natural language. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
The selection and link colors apply not only to the diff panel, but also to the the commit list. Move these right after the generic background and text color options. The color for marked lines is only used in the diff panel, hence, leave it below the diff color options. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Since the provenance of code generated by AI cannot be tracked with confidence, which would be necessary to sign off a contribution, tell contributors not to use AI. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* js/prefs-color-buttons: gitk: move UI for generic colors above diff colors gitk: avoid constructing dialog titles from text pieces gitk: use more natural language for labels of color preferences gitk: show color preferences on the button instead of the label gitk: condense repetitive code around color buttons into foreach loops gitk: set intitial colors of swatches using the available helper
Debian 11 just recently went out of its LTS period, and is unmaintained by the project (there is "Extended LTS", but it is a paid service provided by a third party). The point of the debian-11 job was to cover older releases in the LTS state, per ac112fd (Add additional CI jobs to avoid accidental breakage, 2024-10-31). Bumping to debian-12 will cover us there for the next 2 years. Signed-off-by: Jeff King <peff@peff.net>
While Git for Windows does not _ship_ Python (in order to save on bandwidth), MSYS2 provides very fine Python interpreters that users can easily take advantage of, by using Git for Windows within its SDK. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is no longer true in general, not with supporting Clang out of the box. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option was added in fa93bb2 (MinGW: Fix stat definitions to work with MinGW runtime version 4.0, 2013-09-11), i.e. a _long_ time ago. So long, in fact, that it still targeted MinGW. But we switched to mingw-w64 in 2015, which seems not to share the problem, and therefore does not require a fix. Even worse: This flag is incompatible with UCRT64, which we are about to support by way of upstreaming `mingw-w64-git` to the MSYS2 project, see msys2/MINGW-packages#26470 for details. So let's send that option into its well-deserved retirement. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
That option only matters there, and is in fact only really understood in those builds; UCRT64 versions of GCC, for example, do not know what to do with that option. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In bf2d5d8 (Don't let ld strip relocations, 2016-01-16) (picked from git-for-windows@6a237925bf10), Git for Windows introduced the `-Wl,-pic-executable` flag, specifying the exact entry point via `-e`. This required discerning between i686 and x86_64 code because the former required the symbol to be prefixed with an underscore, the latter did not. As per https://sourceware.org/bugzilla/show_bug.cgi?id=10865, the specified symbols are already the default, though. So let's drop the overly-specific definition. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
MSYS2 already defines a couple of helpful environment variables, and we can use those to infer the installation location as well as the CPU. No need for hard-coding ;-) Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tell-tale is the presence of the `MSYSTEM` value while compiling, of course. In that case, we want to ensure that `MSYSTEM` is set when running `git.exe`, and also enable the magic MSYS2 tty detection. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
MSYS2 defines some helpful environment variables, e.g. `MSYSTEM`. There is code in Git for Windows to ensure that that `MSYSTEM` variable is set, hard-coding a default. However, the existing solution jumps through hoops to reconstruct the proper default, and is even incomplete doing so, as we found out when we extended it to support CLANGARM64. This is absolutely unnecessary because there is already a perfectly valid `MSYSTEM` value we can use at build time. This is even true when building the MINGW32 variant on a MINGW64 system because `makepkg-mingw` will override the `MSYSTEM` value as per the `MINGW_ARCH` array. The same is equally true for the `/mingw64`, `/mingw32` and `/clangarm64` prefix: those values are already available via the `MINGW_PREFIX` environment variable, and we just need to pass that setting through. Only when `MINGW_PREFIX` is not set (as is the case in Git for Windows' minimal SDK, where only `MSYSTEM` is guaranteed to be set correctly), we use as fall-back the top-level directory whose name is the down-cased value of the `MSYSTEM` variable. Incidentally, this also broadens the support to all the configurations supported by the MSYS2 project, i.e. clang64 & ucrt64, too. Helped-by: Johannes Sixt <j6t@kdbg.org> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is merely a historical wart that, say, `git-commit` exists in the `libexec/git-core/` directory, a tribute to the original idea to let Git be essentially a bunch of Unix shell scripts revolving around very few "plumbing" (AKA low-level) commands. Git has evolved a lot from there. These days, most of Git's functionality is contained within the `git` executable, in the form of "built-in" commands. To accommodate for scripts that use the "dashed" form of Git commands, even today, Git provides hard-links that make the `git` executable available as, say, `git-commit`, just in case that an old script has not been updated to invoke `git commit`. Those hard-links do not come cheap: they take about half a minute for every build of Git on Windows, they are mistaken for taking up huge amounts of space by some Windows Explorer versions that do not understand hard-links, and therefore many a "bug" report had to be addressed. The "dashed form" has been officially deprecated in Git version 1.5.4, which was released on February 2nd, 2008, i.e. a very long time ago. This deprecation was never finalized by skipping these hard-links, but we can start the process now, in Git for Windows. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Special-casing even more configurations simply does not make sense. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls for POSIX-1.2008, 2016-07-20). An unintended side-effect is that "cold-calling" into the POSIX emulation will start with a locale based on the current code page, something that Git for Windows is very ill-prepared for, as it expects to be able to pass a command-line containing non-ASCII characters to the shell without having those characters munged. One symptom of this behavior: when `git clone` or `git fetch` shell out to call `git-upload-pack` with a path that contains non-ASCII characters, the shell tried to interpret the entire command-line (including command-line parameters) as executable path, which obviously must fail. This fixes git-for-windows#1036 Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git for Windows wants to add `git.exe` to the users' `PATH`, without cluttering the latter with unnecessary executables such as `wish.exe`. To that end, it invented the concept of its "Git wrapper", i.e. a tiny executable located in `C:\Program Files\Git\cmd\git.exe` (originally a CMD script) whose sole purpose is to set up a couple of environment variables and then spawn the _actual_ `git.exe` (which nowadays lives in `C:\Program Files\Git\mingw64\bin\git.exe` for 64-bit, and the obvious equivalent for 32-bit installations). Currently, the following environment variables are set unless already initialized: - `MSYSTEM`, to make sure that the MSYS2 Bash and the MSYS2 Perl interpreter behave as expected, and - `PLINK_PROTOCOL`, to force PuTTY's `plink.exe` to use the SSH protocol instead of Telnet, - `PATH`, to make sure that the `bin` folder in the user's home directory, as well as the `/mingw64/bin` and the `/usr/bin` directories are included. The trick here is that the `/mingw64/bin/` and `/usr/bin/` directories are relative to the top-level installation directory of Git for Windows (which the included Bash interprets as `/`, i.e. as the MSYS pseudo root directory). Using the absence of `MSYSTEM` as a tell-tale, we can detect in `git.exe` whether these environment variables have been initialized properly. Therefore we can call `C:\Program Files\Git\mingw64\bin\git` in-place after this change, without having to call Git through the Git wrapper. Obviously, above-mentioned directories must be _prepended_ to the `PATH` variable, otherwise we risk picking up executables from unrelated Git installations. We do that by constructing the new `PATH` value from scratch, appending `$HOME/bin` (if `HOME` is set), then the MSYS2 system directories, and then appending the original `PATH`. Side note: this modification of the `PATH` variable is independent of the modification necessary to reach the executables and scripts in `/mingw64/libexec/git-core/`, i.e. the `GIT_EXEC_PATH`. That modification is still performed by Git, elsewhere, long after making the changes described above. While we _still_ cannot simply hard-link `mingw64\bin\git.exe` to `cmd` (because the former depends on a couple of `.dll` files that are only in `mingw64\bin`, i.e. calling `...\cmd\git.exe` would fail to load due to missing dependencies), at least we can now avoid that extra process of running the Git wrapper (which then has to wait for the spawned `git.exe` to finish) by calling `...\mingw64\bin\git.exe` directly, via its absolute path. Testing this is in Git's test suite tricky: we set up a "new" MSYS pseudo-root and copy the `git.exe` file into the appropriate location, then verify that `MSYSTEM` is set properly, and also that the `PATH` is modified so that scripts can be found in `$HOME/bin`, `/mingw64/bin/` and `/usr/bin/`. This addresses git-for-windows#2283 Note: This keeps the same, hard-coded MSYSTEM platform support for CMake as before, and introduces an `msystem' and `mingw-prefix` knob for Meson (read: neither CMake nor Meson will automatically inherit the setting from the current build environment). Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
These days, the test cases are less free-form than in the wild old days of the Git project. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our "documentation" job has recently stopped working with the following error: + sudo gem install --version 1.5.8 asciidoctor + gem install --version 1.5.8 asciidoctor ./ci/install-dependencies.sh: 23: gem: not found The root cause of this is that we never explicitly install Ruby, and consequently gem(1) isn't explicitly pulled in, either. This used to work alright because we transitively pulled in Ruby via asciidoc. But due to an update it seems that we stopped pulling in the transitive dependency, and consequently we don't have gem(1) available anymore. Fix this by explicitly installing Ruby. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our install-dependencies script avoids installing asciidoctor if the CI environment claims to have it already. But the only environment which made use of this was Azure Pipelines, which went away in 6081d38 (ci: retire the Azure Pipelines definition, 2020-04-11). So this conditional was effectively doing nothing. Let's clean it up. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of https://github.com/j6t/gitk: gitk: discourage AI contributions gitk: move UI for generic colors above diff colors gitk: avoid constructing dialog titles from text pieces gitk: use more natural language for labels of color preferences gitk: show color preferences on the button instead of the label gitk: condense repetitive code around color buttons into foreach loops gitk: set intitial colors of swatches using the available helper
The CI job for Debian 11 has been updated to use Debian 12, as the former is now out of the LTS period. * jk/ci-bump-debian-to-12: ci: bump debian-11 job to debian-12
The CI script to install dependencies for the documentation build has been updated to install asciidoctor directly via the system package manager instead of pinning to an older version via gem. Additionally, an obsolete variable used for retired Azure Pipelines environments has been removed. * jk/ci-use-system-asciidoctor: ci: drop ALREADY_HAVE_ASCIIDOCTOR variable ci: fix missing Ruby dependency in "documentation" job
A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. * js/mingw-build-updates: t0060: adjust the code style mingw: allow `git.exe` to be used instead of the "Git wrapper" mingw: ensure valid CTYPE mingw: always define `ETC_*` for MSYS2 environments windows: skip linking `git-<command>` for built-ins mingw: rely on MSYS2's metadata instead of hard-coding it mingw: only enable the MSYS2-specific stuff when compiling in MSYS2 mingw: set the prefix and HOST_CPU as per MSYS2's settings mingw: avoid over-specifying `--pic-executable` mingw: only use -Wl,--large-address-aware for 32-bit builds mingw: drop the -D_USE_32BIT_TIME_T option mingw: stop hard-coding `CC = gcc` mingw: include the Python parts in the build
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )