[pull] master from git:master#87
Merged
pull[bot] merged 48 commits intoturkdevops:masterfrom Aug 5, 2025
Merged
Conversation
When commit-msg writes the file using CRLF, the lines in the final message include trailing spaces. Postpone stripping until after hooks execute. This aligns with Git's behavior, which passes the original message to commit-msg, then strips comments and whitespace. Signed-off-by: Orgad Shaneh <orgads@gmail.com>
External tools such as Jujutsu may add many references that are of no interest to the user. This preference allows hiding them. Signed-off-by: Ori Avtalion <ori@avtalion.name>
gitk's color selection dialog uses a number of "label" widgets to show the current value of each selectable color. This uses the -background color property of label widgets, and this property is overwritten when the full ui color set is refreshed. The swatch colors are set individually using code passed into the chooser dialog, so there is no common routine to set all after updating the global ui colors. Let's replace this with a single routine that does set all swatches, removing a key impediment to restoring the ui colors if the dialog is cancelled. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
gitk provides a dialog to configure many ui colors. Any color element changed in the dialog takes immediate effect before closing the dialog. While cancelling the dialog after changing one or more colors avoids saving the modified colors, the user must restart gitk to restore the prior color set. This unfortunate behavior results because gitk does not have a single routine to update all of the ui colors. The prior commit eliminated the key impediment to having such a routine. So, let's create a routine to update all configured colors at once, use this when modifying colors, and also invoke this after restoring the prior set if the dialog is cancelled. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
TclTk 8.7 (still in alpha), and 9.0 (released), implement TIP 474 that delivers uniform handling of mouse and touchpad scrolling events on all platforms, and by default bound to most widgets. TIP 474 also implements use of the Option- modifier key (Alt- key on PC, Option- key on Macs) to indicate desire for more motion per scroll wheel event, the amplification is not defined but seems to be 5x to 10x. So, for TclTk >= 8.7 we can use identical MouseWheel bindings on all platforms, and should enable use of the Option- modifier to enable larger motion. Let's do all of this, and use a 5x multiplier for the Option- modifier. This largely follows the prior win32 model, except that Tk 8.6 does not reliably use the Option- modifier because the Alt- key conflicts with builtin behavior to activate the main menubar. Presumably this conflict is addressed in the win32 Tcl9.x package. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
gitk uses '-encoding binary' in several places to handle non-text data.
Per TIP 699, this is not recommended as there has been too much
confusion and misconfiguration of binary channels, and this option is
removed in Tcl 9.
Tcl defines a binary channel as one that reproduces the input data
exactly. As Tcl stores all data internally in unicode format, a binary
channel requires 3 things:
- -encoding iso8859-1 : this causes each byte of input to be translated
to its unicode equivalent (may be multi-byte).
- -translation lf : this avoids any translation of line endings, which
by default are translated to \n on input.
- -eofchar {} : this avoids any use of an end of file character, which
is ctrl-z by default on Windows.
The recommended '-translation binary' makes all three settings, but this
is not done in gitk now. Rather, gitk uses '-encoding binary', which is
an alias to '-encoding iso8859-1' removed by TIP 699, in multiple places,
and -eofchar {} in one place but not all. All other files, configured in
non-binary fashion, have -eofchar {}.
Unix and Windows differ on line ending conventions, Tcl by default
converts line endings to \n on input, and to those common on the
platform on output. git emits only \n on Unix or Windows. Also, Tcl's
proc gets recognizes and removes \n, \r, or \r\n as line endings, and
this is used by gitk except in procs selectline and parsecommit. But,
those two procs recognize any combination of \n and \r as terminating a
line. So, there is no need to translate line endings on input, and using
-translation binary avoids any such translation.
Tcl sets eofchar to ctrl-z (ascii \0x1a) only on Windows, otherwise
eofchar is {}. This provides compatibility to old DOS based codes and
files originating when file systems recorded only sectors allocated, and
not bytes used. git does not use ctrl-z to terminate data anywhere. Only
two channels in gitk leave eofchar at the default value, both use
-encoding binary now. A third one was converted in commit 681c329
("gitk: Handle blobs containing a DOS end-of-file marker", 2009-03-16),
fixing such a problem of early data termination. Using eofchar {} is
correct, even if not always necessary.
Tcl 9 forces change, using -translation binary per TIP 699 does what
gitk needs and is backwards compatible to Tcl 8.x. Do it.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
gitk looks for configuration files under $(HOME)/.., and uses the typical shortcut formats to find this, e.g., ~/.config/. This relies upon Tcl expanding such constructs to replace ~ with $(HOME). But, Tcl 9 has stopped doing that for various reasons, and now supplies [file tildeexpand ...] to perform this expansion. There are a very few places that need this expansion, and all must be modified regardless of approach taken. POSIX specifies that $HOME be defined at the time of login, and both Cygwin and MSYS (underlying git for windows) set this variable. Tcl8 uses the POSIX defined pwnam to look up the underlying database record on Unix, but will get the same result as using $HOME on any POSIX compliant system. On Windows, Tcl just accesses $HOME, falling back to other environment variables if $HOME is not set. Git for Windows has $HOME defined by MSYS, so this works just as on the others. As $env(HOME) works in Tcl 8 and 9, while anything using [file tildeexpand ... ] will not, let's use the simpler approach as doing so adds no lines of code. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
gitk invokes many git commands expecting output in utf-8 encoding, but git accepts extended ascii (code page unknown) as utf-8 without validating, so cannot guarantee valid utf-8 on output. In particular, using any extended ascii code page, of which there are many, has long been acceptable given that everyone on a project is aware of and uses that same code page to view all data. utf-8 accepts only 7-bit ascii characters in single bytes, and any characters outside of that base set require at least two bytes. Tcl is a string based language, and transcodes all input data to an internal unicode format, and to whatever format is requested on output: "pure" binary is recoded using iso8859-1. Tcl8.x silently recodes invalid utf-8 as binary data, so extended ascii characters maintain their binary value on output but may not display correctly. Tcl 8.7 added three profiles to control this behaviour: strict (raises exceptions), replace (replaces each invalid byte with ?), and the default tcl8 maintaining the old behavior. Tcl 9 changes the default profile to strict, meaning any invalid utf-8 raises an exception that gitk does not handle. An example of this in the git repository is commit 7eb93c8 ("[PATCH] Simplify git script", 2005-09-07). This includes extended ascii characters in the author name and commit message. As a result, gitk + Tcl 9 cannot view the git repository at any point beyond that commit. Note: Tcl 9.0 has a bug, to be fixed in 9.1, where this particular condition results in a memory error causing Tcl to crash [1]. The tcl8 profile used so far has acceptable behavior given gitk's acceptance: this allows gitk to accept extended ascii though it may display incorrectly. Let's continue that behavior by overriding open to use the tcl8 profile on Tcl9 and later: Tcl 8.6 does not understand fconfigure -profile, and Tcl 8.7 maintains the tcl8 profile. [1] Per https://core.tcl-lang.org/tcl/tktview/73bb42fb3f35cd613af6fcea465e35bbfd352216 Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
gitk in the prior commit learned to apply -profile tcl8 to all input data streams, avoiding errors on non-binary data streams whose encoding is not utf-8. But, gitk also consumes binary data streams (generally blobs from commits), and internally decodes this to support various displays. With Tcl9, errors occur in this decoding for the same reasons described in the previous commit: basically, the underlying data was not validated to conform to the given encoding, and this source encoding may not be utf-8. gitk performs this decoding using Tcl's '[encoding convert from' operator. For example, the 7th commit in gitk's history has the extended ascii value 0xA9, so gitk 9a40c50 in gitk's repository raises an exception. The error log has: unexpected byte sequence starting at index 11: '\xA9' while executing "encoding convertfrom $diffencoding $line" (procedure "parseblobdiffline" line 135) invoked from within "parseblobdiffline $ids $line" (procedure "getblobdiffline" line 16) invoked from within "getblobdiffline file6 9a40c50" ("eval" body line 1) invoked from within "eval $script" (procedure "dorunq" line 11) invoked from within "dorunq" ("after" script) This problem has a similar fix to the prior issue: we must use the tlc8 profile when converting this data. Do so, again only on Tcl9 as Tcl8.6 does not recognize -profile, and only Tcl 9.0 makes strict the default. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Tcl/Tk 9.0 has been released, and has shipped in Fedora 42. Prior patches in this sequence have addressed known incompatibilities, so gitk is now operating with Tcl9. So, let's allow Tcl9. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
git-gui on Windows prepends three directories to PATH so does not honor PATH as configured. This can have undesirable consequences, for instance by preventing use of a different git for testing. This also provides at best a subset of the configuration included with Git for Windows (g4w), so is neither necessary nor sufficient there. Since commit be700fe, git-gui.sh adds its directory to the front of PATH: this is essentially adding $(git --execdir) to the path, this is long deprecated as git moved to using "dashless" subcommands. The windows/git-gui.sh wrapper file, since commit 99fe594, adds two directories relative to its installed location to PATH, and does so without checking that either exists or is needed. The above modifications were made before the Git For Windows project took responsibility for distributing a working solution on Windows. g4w assures a correct configuration on Windows without these, and doing so requires more than the above modifications. See [1] for a more thorough treatment. git-gui does not modify PATH on any platform except on Windows, and doing so is not needed by g4w. Let's stop modifying PATH on Windows as well. [1] https://gitforwindows.org/git-wrapper.html Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
git-gui runs blame and diff commands with nice by default. On Unix, nice is accepted if found and it will run git. Commit ff9db6c ("On Windows, avoid git-gui to call Cygwin's nice utility", 2010-10-05) rejects nice if not collocated with git. In Git for Windows' (g4w) POSIX path name space, nice and git are found in different directories: $ which git /mingw64/bin/git $ which nice /usr/bin/nice Thus, git-gui will not use nice in the supported Windows configuration. Commit ff9db6c justifies the collocation requirement as avoiding problems in a mixed MSYS and Cygwin configuration: such configurations are not supported by either project as they are known to cause many problems. So, let's revert ff9db6c and let git-gui work correctly in the supported configuration. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
git-gui invokes the tk_getSaveFile dialog to determine the full path-name of the shortcut file to create. But, on Windows, this dialog always dereferences a shortcut (.lnk) file, as this is essentially a soft-link to its target. If the shortcut file already exists, the dialog returns the path-name of the target (i.e., GIT/cmd/git-gui.exe), and not the desired shortcut file selected by the user. There is no Windows file chooser available in Tcl/Tk that does not dereference .lnk files, so this patch avoids using a dialog: the shortcut to be created is on the desktop and named as "Git + Repository Name". If this .lnk file already exists, the user must give permission to overwrite it or the process terminates. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
git-gui on Windows creates a shortcut that presumes the git-gui script will run on the basic Windows environment as configured. But, Git for Windows uses wrapper scripts to launch executables, assuring the environment is correct (see [1] for details). The launcher for git-gui is /cmd/git-gui.exe, is not on PATH, and is not detected or used by the current shortcut code. Let's look for this before trying the existing approaches. [1] https://gitforwindows.org/git-wrapper.html Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Per 6eb420e ("git-gui: Always disable the Tcl EOF character when reading", 2007-07-17), git-gui should disable Tcl's EOF character detection on all files when on Windows: the default is disabled on all other platforms (and with Tcl 9.0, is disabled on Windows too). This EOF character is for compatibility with files / applications written for file systems that know only the disc sectors allocated, and not the number of bytes used. This has nothing to do with git. But, git-gui does not set -eofchar {} on all channels. To avoid any further leakage, let's just add this to the Windows specific override of open. This override is needed only as long as Tcl 8.x is in use (Tcl 9.0 makes -eofchar {} default on all platforms). Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
git-gui has many cases where -translation binary and -encoding binary are configured on the same channel. But, -translation binary defines a binary channel, which sets up -encoding iso8859-1 as part of its work. Tcl 8.x defines -encoding binary as an alias of -encoding iso8859-1, and this alias is deleted in Tcl 9.0. Let's delete the redundant encoding definition now. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
git-gui currently configures some channels as '-encoding binary' when the channel is not really binary (e.g, the channel is consumed as lines of text). In 8.6, '-encoding binary' is an alias for '-encoding iso8859), but TIP 699 removes this alias for Tcl 9.0. Let's switch to '-encoding iso8859-1' to be compatible across Tcl versions. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
git-gui has many instances of '-translation binary' and '-encoding $SOMETHING' on the same channel. As eofchar is always null given a prior commit, the net effect of having '-translation binary' in such configuration is only to change how text line endings are handled. For cases where the channel is opened to be consumed via gets, the eol translation is irrelevant because Tcl's gets is documented to recognize any of \n, \r, and \r\n as a line ending. So, keep only the '-encoding $SOMETHING' configuration in these cases, making the configuration more clear. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
This makes sending diffs via mail list easier and brings the po-file in line with git po-file. Signed-off-by: Alexander Shopov <ash@kambanaria.org>
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
This makes sending diffs via mail list easier and brings the po-file in line with git po-file. Signed-off-by: Alexander Shopov <ash@kambanaria.org>
It is possible that multiple local branches track the same upstream. In this case, the refs dialog lists the tracked upstream branch multiple times. This is undesirable. Make them unique. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
In refill_reflist, upstream refs are now only included if their commits are visible in the current view. This prevents display issues like multiple highlighted branches when clicking entries. Signed-off-by: Michael Rappazzo <michael.rappazzo@infor.com>
Last used in ae49066 (git gui Makefile - remove Cygwin modifications, 2023-06-26), and unused since. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Since 854e883 (git-gui: extract script to generate "git-gui", 2025-03-11), the logic to generate the main script was pulled out of the Makefile, but adding the resulting generator as a dependency was missed. If the logic changes, the main script should be regenerated, so add it as a dependency. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
In a recent commit, the minimum version of Tcl/Tk was raised to 8.6, but the "app" relies on the system provided Framework that is based on 8.5. Remove it, and let git-gui use a third party version of Wish if available. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Since its introduction in 8c76212 (git-gui: Add a simple implementation of SSH_ASKPASS., 2008-10-15), git-gui--askpass has been calling whatever wish interpreter is in the path, unlike git-gui. Correct that by turning it into a script that would be processed at build time. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* ml/windows-tie-loose-ends: git-gui: use /cmd/git-gui.exe for shortcut git-gui: Windows tk_getSaveFile is not useful for shortcuts git-gui: let nice work on Windows git-gui: do not add directories to PATH on Windows Signed-off-by: Johannes Sixt <j6t@kdbg.org>
git-gui configures '-translation lf' on a number of channels. The default configuration is 'auto', which on input changes any occurrence of \n, \r, or \r\n to \n, and on output changes any such EOL sequence to a platform dependent value (\n on Unix, \r\n on Windows). Such translation can be necessary, but much of what is configured now is redundant. In particular, many of the channels configured this way are then consumed by gets, which already recognizes any of \n, \r, or \r\n as terminators. Configuring a channel to first change these line endings, then give the result to gets, is redundant. The valid uses of -translation lf are for output where we do not want \r\n on Windows, and for consuming entire files without going through gets, assuring that \n will be used internally. Let's remove all the others that only serve to confuse. lib/diff.tcl must have -translation lf because \r\n might be stored in the repository (e.g., on Windows, with no crlf translation enabled), and git will treat \n as the line ending, while the preceding \r is just whitespace, and these may be split by ANSI color coding. git-gui's read_diff handles this correctly as-is. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Tcl 9 imposes strict requirements on namespaces for variables, while Tcl 8 does not. lib/themed.tcl does not use the fully qualified name for the "color" namespace, with result that variables are not found with Tcl 9.0. Fix this. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
git-gui invokes many git commands expecting output in utf-8 encoding, but git accepts extended ascii (code page unknown) as utf-8 without validating, so cannot guarantee valid utf-8 on output. In particular, using any extended ascii code page has long been acceptable on git given that everyone on a project is aware of and uses that same code page to view all data. utf-8 accepts only 7-bit ascii characters in single bytes, and any characters outside of that base set require at least two bytes for representation in unicode. Tcl is a string based language, and transcodes all input data to an internal unicode format, and to whatever format is requested on output: "pure" binary is recoded byte by byte using iso8859-1. Tcl8.x silently recodes invalid utf-8 as binary data, so extended ascii characters maintain their binary value on output but may not display correctly. Tcl 8.7 added three profiles to control this behaviour: strict (raises exceptions), replace (replaces each invalid byte with ?), and the default tcl8 maintaining the old behavior. Tcl 9 changes the default profile to strict, meaning any invalid utf-8 raises an exception that git-gui does not handle. An example of this in the git repository is commit 7eb93c8 ("[PATCH] Simplify git script", 2005-09-07). This includes extended ascii characters in the author name and commit message. The tcl8 profile used so far has acceptable behavior given git-gui's acceptance: this allows git-gui to accept extended ascii though it may display incorrectly. Let's continue that behavior by overriding open to use the tcl8 profile on Tcl9 and later: Tcl 8.6 does not understand fconfigure -profile, and Tcl 8.7 maintains the tcl8 profile. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
git-gui in the prior commit learned to apply -profile tcl8 when reading files, avoiding errors on non-binary data streams whose encoding is not utf-8. But, git-gui also consumes binary data streams (generally blobs from commits) as the output of commands, and internally decodes this to support various displays. With Tcl9, errors occur in this decoding for the same reasons described in the previous commit: basically, the underlying data may contain extended ascii characters violating the assumption of utf-8 encoding. This problem has a similar fix to the prior issue: we must use the tlc8 profile when converting this data to the internal unicode format. Do so, again only on Tcl9 as Tcl8.6 does not recognize -profile, and only Tcl 9.0 makes strict the default. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
TclTk 9.0 is now shipping, and git-gui is now patched to support use of this newer version. Adjust required versions to allow Tcl/Tk >= 8.6, including 9.x. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
* mr/sort-refs-by-type: gitk: filter invisible upstream refs from reference list gitk: avoid duplicated upstream refs Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* 'master' of github.com:alshopov/gitk: gitk i18n: Remove the locations within the Bulgarian translation gitk i18n: Update Bulgarian translation (322t) Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* ml/abandon-old-version: gitk: restore ui colors after cancelling config dialog gitk: set config dialog color swatches in one place Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* oa/hide-more-refs: gitk: Add user preference to hide specific references Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* ml/tcltk-9: gitk: allow Tcl/Tk 9.0+ gitk: use -profile tcl8 on encoding conversions gitk: use -profile tcl8 for file input with Tcl 9 gitk: Tcl9 doesn't expand ~, use $env(HOME) gitk: switch to -translation binary gitk: update scrolling for TclTk 8.7+ / TIP 474 Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* 'master' of https://github.com/alshopov/git-gui: git-gui i18n: Remove the locations within the Bulgarian translation git-gui i18n: Update Bulgarian translation (557t) Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* ml/tcl90:
git-gui: Allow Tcl 9.0
git-gui: use -profile tcl8 on encoding conversions
git-gui: use -profile tcl8 for file input with Tcl 9
git-gui: themed.tcl: use full namespace for color
git-gui: remove EOL translation for gets
git-gui: do not mix -translation binary and -encoding
git-gui: replace encoding binary with iso8859-1
git-gui: translation binary defines iso8859-1
git-gui: assure -eofchar {} on all channels
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* 'strip-post-hooks' of github.com:orgads/git-gui: git-gui: strip the commit message after running commit-msg hook Signed-off-by: Johannes Sixt <j6t@kdbg.org>
This clarifies that one has to enter e.g. `jj/keep/*` and not just `jj/keep`. Follows up on 2441e19. Signed-off-by: Ilya Grigoriev <ilyagr@users.noreply.github.com>
* 'docglobs' of github.com:ilyagr/gitk: gitk: Mention globs in description of preference to hide custom refs Signed-off-by: Johannes Sixt <j6t@kdbg.org>
When finding a location for the askpass helper, git will be asked for its exec path, but if that git is not the same that called git-gui then we might mistakenly point to its helper instead. Assume that git-gui and the helper are colocated to derive its path instead. This is specially useful in macOS where a broken version of that helper is provided by the system git. [j6t: move directory to variable to help in-flight topics] Suggested-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* cb/no-tcl86-on-macos: git-gui: ensure own version of git-gui--askpass is used git-gui: honor TCLTK_PATH in git-gui--askpass git-gui: retire Git Gui.app git-gui: fix dependency of GITGUI_MAIN on generator git-gui: remove uname_O in Makefile
* 'master' of https://github.com/j6t/gitk: gitk: Mention globs in description of preference to hide custom refs gitk: filter invisible upstream refs from reference list gitk: avoid duplicated upstream refs gitk i18n: Remove the locations within the Bulgarian translation gitk i18n: Update Bulgarian translation (322t) gitk: allow Tcl/Tk 9.0+ gitk: use -profile tcl8 on encoding conversions gitk: use -profile tcl8 for file input with Tcl 9 gitk: Tcl9 doesn't expand ~, use $env(HOME) gitk: switch to -translation binary gitk: update scrolling for TclTk 8.7+ / TIP 474 gitk: restore ui colors after cancelling config dialog gitk: set config dialog color swatches in one place gitk: Add user preference to hide specific references
* 'master' of https://github.com/j6t/git-gui: (21 commits) git-gui: ensure own version of git-gui--askpass is used git-gui: Allow Tcl 9.0 git-gui: use -profile tcl8 on encoding conversions git-gui: use -profile tcl8 for file input with Tcl 9 git-gui: themed.tcl: use full namespace for color git-gui: remove EOL translation for gets git-gui: honor TCLTK_PATH in git-gui--askpass git-gui: retire Git Gui.app git-gui: fix dependency of GITGUI_MAIN on generator git-gui: remove uname_O in Makefile git-gui i18n: Remove the locations within the Bulgarian translation git-gui i18n: Update Bulgarian translation (557t) git-gui: do not mix -translation binary and -encoding git-gui: replace encoding binary with iso8859-1 git-gui: translation binary defines iso8859-1 git-gui: assure -eofchar {} on all channels git-gui: use /cmd/git-gui.exe for shortcut git-gui: Windows tk_getSaveFile is not useful for shortcuts git-gui: let nice work on Windows git-gui: do not add directories to PATH on Windows ...
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.
8 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.3)
Can you help keep this open source service alive? 💖 Please sponsor : )