[pull] master from git:master#218
Merged
Merged
Conversation
When many branches and tags decorate the same commit, the ref labels push the commit description far to the right, often out of the visible area of the left pane. The canvas widget already tracked the maximum x extent via canvxmax and updated its scrollregion accordingly, but there was no scrollbar wired up to let the user reach that content. Add a horizontal scrollbar (.tf.histframe.cxsb) below the three-pane history area, connected to the left canvas (canv) via its xscrollcommand and xview. No behaviour is changed for the author (canv2) or date (canv3) panes; they continue to scroll only vertically in lock-step as before. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Rob McDonald <rob.a.mcdonald@gmail.com>
commit f87a36b ("git-gui: use git-branch --show-current", 2024-02-12) changed git-gui to use git-branch to access refs, rather than directly reading files as doing the latter is not compatible with the reftable backend. git branch --show-current reports an empty branch name when the head is detached, and in this case load_current_branch needs to report HEAD using special case logic as it did prior to the above commit. Make it do so. This addresses an issue with git-gui browser failing with a detached head. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
In the procedure that invokes Gitk, we have a 'cd $_gitworktree'. Such a change of the current directory is not necessary, because - if we have a working tree, then the startup routine has already changed the current directory to the root of the working tree, which *is* $_gitworktree; or - if we are in a bare repository, then there is no point in changing the current directory anywhere. (And $_gitworktree is empty.) Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
git-gui unconditionally exports _gitdir as GIT_DIR, and _gitworktree as GIT_WORK_TREE, to the environment, and unconditionally unsets these environment variables before invoking gitk or git-gui when a submodule is involved. This export happens even if _gitworktree is empty, which happens when running from a bare repository. However, exporting GIT_WORK_TREE as empty is never valid, and causes errors in git. GIT_DIR must be exported if the repository is not discoverable from the worktree (or current directory if there is no worktree). The user might have configured this. If there is a worktree, git-gui makes this the current directory. However, if the repository sets core.worktree, this value can only be overridden by GIT_WORK_TREE so the latter must be exported. As we cannot eliminate conditions where either variable is needed, let's implement a pair of functions to set / unset these variables without error, and without ever exporting an empty GIT_WORK_TREE. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
The repository picker (choose_repository::pick, AKA pick) on success
always returns with the current directory at the root of the selected
worktree, with the global variable _gitdir holding the name of the
git repository, possibly as a relative path, and _prefix {}. The
worktree root (_gitworktree) is not filled out, and if the selection was
from the "recent" list, no validation has occurred beyond testing that
the worktree root exists. So, repository and worktree validation are
still needed to be sure the new repo + worktree is usable.
pick only supports worktrees with a .git entry in the worktree root, so
git repository and worktree discovery will work starting in the current
directory on return. In cases of error, or user abort, pick exits the
process rather than returning.
So, let's change pick to not alter any global values, with success
indicated by the process returning to the caller. In this case, the
current directory is the worktree root, with a .git entry. The caller
then proceeds with normal discovery to find and validate both repository
and worktree.
With this, pick now returns 1 in the success case, but additional work
would be necessary to return from conditions where 0 should be returned.
Checking this return value would be superfluous.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
git-gui uses git rev-parse --git-dir to get the pathname of the discovered git repository. The returned value can be relative, and is '.' if the current directory is the top of the repository directory itself. git-gui has code to change '.' to [pwd] in this case so that subsequent logic runs. But, git rev-parse supports --absolute-git-dir from fac60b8 ("rev-parse: add option for absolute or relative path formatting", 2020-12-13), and included in git 2.31. git-gui requires git >= 2.36, so this more useful form is always available. Use --absolute-git-dir to always get an absolute path, avoiding the need for other checks, and delete the now unneeded code to fix a relative _gitdir. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
git-gui attempts to use env(GIT_DIR) directly as the git repository,
accepting GIT_DIR if it is a directory. Only if that fails is git
rev-parse used to discover the repository. But, this avoids all of
git-core's validity checking on a repository, thus possibly deferring an
error to a later step, possibly unexpected. Repository validation should
be part of initial setup so that later processing does not need error
trapping for configuration errors.
Let's just invoke rev-parse so all error checking is done.
While here, let's cleanup the error handling.
Stop if an error occurs and the user set GIT_DIR or GIT_WORK_TREE.
Use of either or both of those variables is supported by git, but their
use also means the user has taken responsibility that they are correct,
so a failure is something the user must address.
Otherwise on error, continue the existing behavior and show the
repository picker. But, let's move the possible invocation of
repository_chooser::pick to a separate code block. This permits adding
separate conditions on using pick independent of repository discovery, and
will be exploited later in the series. Note that the picker always
returns with the current directory in the root of a worktree with the
git repository is in the .git subdirectory. The variable "picked" is
used by git-gui to automatically execute the "Explore Working Copy" menu
item after the repository picker is run. This is controlled by config
variable gui.autoexplore, and happens after all discovery is complete.
Remove a later check on whether _gitdir is a directory: that code
cannot be reached without rev-parse already validating the repository.
_prefix is set as part of worktree discovery, but must be {} if not
running with a worktree. Initialze this as {} along with other global
variables, this is the correct value is no worktree is found.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
git gui uses a combination of tcl code and git invocations to determine the worktree and the location with respect to the worktree root (_prefix). But, git rev-parse provides all of this information directly, and assures full error and configuration checking are done by git itself. The entirety of discovery in normal configurations involves git rev-parse --show-toplevel (gets worktree root) git rev-parse --show-prefix (shows location wrt the root) An error thrown on either of these lines means the worktree discovered by git is unusable, or git did not discover a worktree because the current directory is inside the repository. If the user has defined GIT_DIR or GIT_WORK_TREE, this is a user configuration error and git-gui should stop. Otherwise, the blame or browser subcommands can be used without a worktree. A separate error might occur when changing to the root of the discovered worktree. The cause would be file system related and completely outside of git's control, so trap that independently. Discovery of the repository and the worktree must be guarded to trap errors: the intent is that any configuration problems are caught during discovery, and later processing need not include error trapping and recovery. So, move all worktree discovery code to be immediately after repository discovery. This does move configuration loading to occur after worktree discovery rather than before. None of the code executed in worktree discovery has any option controlled by a git-gui configuration variable, so no impact is expected. git itself will always read the repository configuration, including worktree specific configuration data if that exists, so this is unaffected by when git-gui loads its own config data. Also, we cannot be sure the worktree dependent configuration can be loaded before full discovery is complete. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
git-gui includes proc is_bare, used in several places to make decisions on whether a worktree exists, but also in discovery to tell if a worktree can be supported. But, is_bare is out of date with regard to multiple worktrees, safe repository guards, and possibly other relevant features known to git rev-parse. Also, is_bare caches its result on the first call, so is not useful if a later step in the discovery process finds a worktree. So, simplify is_bare to report whether git-gui has a worktree or is working only from a repository. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
git-gui, since 87cd09f ("git-gui: work from the .git dir", 2010-01-23), has had the intent to allow starting from inside a repository, then switching to the parent directory if that is a valid worktree. This certainly hasn't worked since 2d92ab3 ("rev-parse: make --show-toplevel without a worktree an error", 2019-11-19) in git, but breaking this git-gui feature was unintentional. There are (at least) 3 cases where the gitdir can tell us where the worktree is, and we would like all to work: - core.worktree is set, and points to a valid worktree. This is already handled by git rev-parse --show-toplevel, even when not in the worktree. There is nothing more to do in this case. - the gitdir is embedded in a worktree as subdirectory .git. The parent is (or at least should be) a valid worktree. This worked long ago. - the gitdir is a worktree specific directory (under <mainrepo>/worktrees/worktree_name), within which there is a file "gitdir" pointing to .git in the worktree. git gui never learned to handle this case. Let's handle the latter two cases. Always check that the discovered worktree is valid and points to the already discovered gitdir according to git rev-parse. This avoids issues that may arise because we are discovering from the gitdir up, rather than the worktree down, and file system non-posix behavior or misconfiguration of git might cause confusion. For instance, a manually moved worktree might not be where the gitdir points, or the gitdir might be configured with core.bare=true. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Invoking "git-gui browser rev ." should show the file browser for the commitish rev, starting at the current directory. When the current directory is the working tree root, this errors out in normalize_relpath because the '.' is removed, yielding an empty list as argument to [file join ...]. git ls-tree (underlying the browser) accepts '.', so use that as the value when in the root. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
git gui offers two related commands, browser and blame, that provide graphical interfaces driven by git ls-tree and git blame. As such, the arguments to git-gui need to satisfy those two git commands. But, git-gui does not assure this leading to confusing or incorrect results. For instance 'git browser <non-existent path>' shows a blank browser window rather than error message. Also, commit 3e45ee1 ("git-gui: Smarter command line parsing for browser, blame", 2007-05-08) implemented code to allow giving path before rev on the command line, and unconditionally uses the worktree to disambiguate. As a result, the following command run in a current git-gui checkout of the master branch shows the master branch version of blame.tcl, when none should be shown as that file does not exist in gitgui-0.6.0. git gui blame lib/blame.tcl gitgui-0.6.0 This 'file before rev' feature in git-gui mirrors ideas considered when git's user interface was very young, but no such feature is documented for any git command. Rather than try to fix an idea git itself rejected, let's just remove this broken and hopefully unused feature. git-gui browser|blame both accept 'rev' and 'path' as command line arguments. rev defaults to 'HEAD' if not given, while path must be given. path names a directory tree to ls-tree or a file to blame. path must exist in rev for ls-tree and for blame. In addition git blame will include uncommitted changes from the worktree file at 'path' if rev is not given (thus defaulting to HEAD), but still requires that the file exists in HEAD. So, let's clean up the parser to check that the arguments are usable. - give a full synopsis, including '--' that may be used to separate rev and path. (as path is the required final arg, -- gives no extra info) - explicitly check the number of arguments - use rev-parse to assure a user supplied rev is valid - use ls-tree to assure that path exists in rev - for blame only, with no rev given and a worktree existing, also assure that path points to a file in the worktree With these changes, error messages are thrown by the parser if the path or rev are not known: no blank or erroneous displays are created. Also, this avoids accessing the worktree except in the specific use case supported by blame / git-blame, meaning browser|blame now also work without a worktree. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
git-gui accepts subcommands blame | browser | citool, and assumes the
subcommand is 'gui' if none is actually given, But, git-gui also has a
repository picker (choose_repository::pick) that can create a new
repository + worktree, or choose an existing one, switch to that, and
the run the gui. The user has no direct control over invoking the
picker, instead the picker is triggered by failure in the repository /
worktree discovery process: this includes being started in a directory
not controlled by git, which is probably the intended use case.
The picker can appear when the user has no intention of creating a new
worktree, and the user cannot use the picker to create a new worktree
inside another.
So, add two explicit subcommands:
gui - Run the gui if repository/worktree discovery succeeds, or die
with an error message, but never run the picker.
pick - First run the picker, regardless, then start the gui in
the chosen worktree.
Nothing in this changes the prior behavior, the alternates above must be
explicitly selected to see any change.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Several install and uninstall recipes embed "echo" calls that fire as part of the recipe itself, so the install banners (DEST, INSTALL, LINK, REMOVE) were visible whenever the variables expand non-empty. Guard the whole "ifndef V" block on "-s" so the loud variants are selected only when "-s" is absent and V=1 is unset. The existing "-s" check also had its findstring arguments in the wrong order (needle "-s" never fit in haystack "s"), so swap them while moving the check to wrap the block. Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* ml/repo-discovery: git-gui: add gui and pick as explicit subcommands git-gui: check browser/blame arguments carefully git-gui: allow specifying path '.' to the browser git-gui: try harder to find worktree from gitdir git-gui: simplify [is_bare] to report if a worktree is known git-gui: use git rev-parse for worktree discovery git-gui: use rev-parse exclusively to find a repository git-gui: use --absolute-git-dir git-gui: do not change global vars in choose_repository::pick git-gui: guard set/unset of GIT_DIR and GIT_WORK_TREE git-gui: remove unnecessary 'cd $_gitworktree' from do_gitk git-gui: use HEAD as current branch when detached
* 'horizontal-scroll' of github.com:ramcdona/gitk: gitk: add horizontal scrollbar to the commit list pane Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* 'master' of https://github.com/j6t/gitk: gitk: add horizontal scrollbar to the commit list pane
* 'master' of https://github.com/j6t/git-gui: git-gui: silence install recipes under "make -s" git-gui: add gui and pick as explicit subcommands git-gui: check browser/blame arguments carefully git-gui: allow specifying path '.' to the browser git-gui: try harder to find worktree from gitdir git-gui: simplify [is_bare] to report if a worktree is known git-gui: use git rev-parse for worktree discovery git-gui: use rev-parse exclusively to find a repository git-gui: use --absolute-git-dir git-gui: do not change global vars in choose_repository::pick git-gui: guard set/unset of GIT_DIR and GIT_WORK_TREE git-gui: remove unnecessary 'cd $_gitworktree' from do_gitk git-gui: use HEAD as current branch when detached
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 : )