git-gui: fix inability to quit after closing another instance #91
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
|
ping |
Earlier, commit aae9560 introduced search in $PATH to find executables before running them, avoiding an issue where on Windows a same named file in the current directory can be executed in preference to anything in a directory in $PATH. This search is intended to find an absolute path for a bare executable ( e.g, a function "foo") by finding the first instance of "foo" in a directory given in $PATH, and this search works correctly. The search is explicitly avoided for an executable named with an absolute path (e.g., /bin/sh), and that works as well. Unfortunately, the search is also applied to commands named with a relative path. A hook script (or executable) $HOOK is usually located relative to the project directory as .git/hooks/$HOOK. The search for this will generally fail as that relative path will (probably) not exist on any directory in $PATH. This means that git hooks in general now fail to run. Considerable mayhem could occur should a directory on $PATH be git controlled. If such a directory includes .git/hooks/$HOOK, that repository's $HOOK will be substituted for the one in the current project, with unknown consequences. This lookup failure also occurs in worktrees linked to a remote .git directory using git-new-workdir. However, a worktree using a .git file pointing to a separate git directory apparently avoids this: in that case the hook command is resolved to an absolute path before being passed down to the code introduced in aae9560. Fix this by replacing the test for an "absolute" pathname to a check for a command name having more than one pathname component. This limits the search and absolute pathname resolution to bare commands. The new test uses tcl's "file split" command. Experiments on Linux and Windows, using tclsh, show that command names with relative and absolute paths always give at least two components, while a bare command gives only one. Linux: puts [file split {foo}] ==> foo Linux: puts [file split {/foo}] ==> / foo Linux: puts [file split {.git/foo}] ==> .git foo Windows: puts [file split {foo}] ==> foo Windows: puts [file split {c:\foo}] ==> c:/ foo Windows: puts [file split {.git\foo}] ==> .git foo The above results show the new test limits search and replacement to bare commands on both Linux and Windows. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui currently runs some hooks directly using its own code written before 2010, long predating git v2.9 that added the core.hooksPath configuration to override the assumed location at $GIT_DIR/hooks. Thus, git-gui looks for and runs hooks including prepare-commit-msg, commit-msg, pre-commit, post-commit, and post-checkout from $GIT_DIR/hooks, regardless of configuration. Commands (e.g., git-merge) that git-gui invokes directly do honor core.hooksPath, meaning the overall behaviour is inconsistent. Furthermore, since v2.36 git exposes its hook execution machinery via `git-hook run`, eliminating the need for others to maintain code duplicating that functionality. Using git-hook will both fix git-gui's current issues on hook configuration and (presumably) reduce the maintenance burden going forward. So, teach git-gui to use git-hook. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The French word "aperçu", meaning "view" or "preview", contains only a single letter "p". Remove the extra letter, which is an obvious typo. Reported-by: Léonard Michelet <leonard@lebasic.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* ml/git-gui-exec-path-fix: git-gui - use git-hook, honor core.hooksPath git-gui - re-enable use of hook scripts
It's somewhat traditional to respect sites' self-identification. [j6t: cherry-picked from 65175d9ea26b] Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
These sites offer https versions of their content. Using the https versions provides some protection for users. [j6t: cherry-picked from d05b08cd52cf] Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
In GNU Make commit 07fcee35 ([SV 64815] Recipe lines cannot contain
conditional statements, 2023-05-22) and following, conditional
statements may no longer be preceded by a tab character (which Make
refers to as the recipe prefix).
There are a handful of spots in our various Makefile(s) which will break
in a future release of Make containing 07fcee35. For instance, trying to
compile the pre-image of this patch with the tip of make.git results in
the following:
$ make -v | head -1 && make
GNU Make 4.4.90
config.mak.uname:842: *** missing 'endif'. Stop.
The kernel addressed this issue in 82175d1f9430 (kbuild: Replace tabs
with spaces when followed by conditionals, 2024-01-28). Address the
issues in Git's tree by applying the same strategy.
When a conditional word (ifeq, ifneq, ifdef, etc.) is preceded by one or
more tab characters, replace each tab character with 8 space characters
with the following:
find . -type f -not -path './.git/*' -name Makefile -or -name '*.mak' |
xargs perl -i -pe '
s/(\t+)(ifn?eq|ifn?def|else|endif)/" " x (length($1) * 8) . $2/ge unless /\\$/
'
The "unless /\\$/" removes any false-positives (like "\telse \"
appearing within a shell script as part of a recipe).
After doing so, Git compiles on newer versions of Make:
$ make -v | head -1 && make
GNU Make 4.4.90
GIT_VERSION = 2.44.0.414.gfac1dc44ca9
[...]
$ echo $?
0
[j6t: cherry-picked from 728b9ac0c3b9]
Reported-by: Dario Gjorgjevski <dario.gjorgjevski@gmail.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Our top-level Makefile follows our generic whitespace rule established by the top-level .gitattributes file that does not enforce indent-with-non-tab rule by default, but git-gui is set up to enforce indent-with-non-tab by default. With the upcoming change to GNU make, we no longer can reject (and worse, "fix") a patch that adds whitespace indented lines to the Makefile, so loosen the rule there for git-gui/Makefile, too. [j6t: cherry-picked from 227b8fd90240] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Pratyush Yadev has relinquished, and Johannes Sixt has taken over, maintainership of Git-GUI. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Peter Krefting <peter@softwolves.pp.se> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* bc/french-translation: git-gui: po: fix typo in French "aperçu"
* pk/swedish-translation: git-gui: sv.po: Update Swedish translation (576t0f0u)
|
@orgads Sorry, I no longer maintain this. https://github.com/j6t/git-gui is the fork that should be actively maintained. Again, sorry for not replying earlier. |
If you open 2 git gui instances in the same directory, then close one of them and try to close the other, an error message pops up, saying: 'error renaming ".git/GITGUI_BCK": no such file or directory', and it is no longer possible to close the window ever. Fix by catching this error, and proceeding even if the file no longer exists. Signed-off-by: Orgad Shaneh <orgads@gmail.com>
|
@prati0100 Thanks. I'll open a PR there. |
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.
If you open 2 git gui instances in the same directory, then close one of them and try to close the other, an error message pops up, saying: 'error renaming ".git/GITGUI_BCK": no such file or directory', and it is no longer possible to close the window ever.
Fix by catching this error, and proceeding even if the file no longer exists.