forked from jesseduffield/lazygit
-
Notifications
You must be signed in to change notification settings - Fork 0
Feature implementation from commits 946f5f1..aa331e5 #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
yashuatla
wants to merge
15
commits into
feature-base-2
Choose a base branch
from
feature-head-2
base: feature-base-2
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
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
Mention in the PR template that PR titles will be used in release notes. This came up in jesseduffield#4571.
In the unlikely scenario that you have a remote branch on `origin` called `foo`, and a local tag called `origin/foo`, git changes the behavior of the previous command such that it produces ``` $ git for-each-ref --sort=refname --format=%(refname:short) refs/remotes origin/branch1 remotes/origin/foo ``` with `remotes/` prepended. Presumably this is to disambiguate it from the local tag `origin/foo`. Unfortunately, this breaks the existing behavior of this function, so the remote branch is never shown. By changing the command, we now get ``` $ git for-each-ref --sort=refname --format=%(refname) refs/remotes refs/remotes/origin/branch1 refs/remotes/origin/foo ``` This allows easy parsing based on the `/`, and none of the code outside this function has to change. ---- We previously were not showing remote HEADs for modern git versions based on how they were formatted from "%(refname:short)". We have decided that this is a feature, not a bug, so we are building that into the code here.
…rsa (jesseduffield#4571) - **PR Description** Allows the reset menu to have a different name that is displayed, and a fully qualified name that git will unambiguously know what it refers about. We could totally squash this back down to 1 input, and display to the user the _precise_ full ref name that we are resetting to, but I think the context they are in (branches tab versus tag tab), means that we don't need to do that, and can continue to just show the branch name and the tag name to the end users. Fixes jesseduffield#4569
When switching between repos, each repo might have a different focused panel; in this case, the previously focused panel would show the "inactive" highlight. By default this is only bold text, so it's barely noticeable, but it becomes more pronounced when setting e.g. gui: theme: inactiveViewSelectedLineBgColor: - "#666666" I noticed this especially when entering or leaving submodules; for example, enter a submodule by pressing enter in the Files panel, then switch to the Commits panel in the submodule, then press Esc to go back to the parent repo. This would put the focus back into the Files panel, but keep the inactive highlight in the Commits panel.
…eld#4621) - **PR Description** When switching between repos, each repo might have a different focused panel; in this case, the previously focused panel would show the "inactive" highlight. By default this is only bold text, so it's barely noticeable, but it becomes more pronounced when setting e.g. ```yml gui: theme: inactiveViewSelectedLineBgColor: - "#666666" ``` I noticed this especially when entering or leaving submodules; for example, enter a submodule by pressing enter in the Files panel, then switch to the Commits panel in the submodule, then press Esc to go back to the parent repo. This would put the focus back into the Files panel, but keep the inactive highlight in the Commits panel.
Adaptions are for this gocui commit: Cleanup: remove Is* error functions - Use errors.Is instead of quality comparisons. This is better because it matches wrapped errors as well, which we will need later in this branch. - Inline the errors.Is calls at the call sites. This is idiomatic go, we don't need helper functions for this. See https://go.dev/blog/go1.13-errors for more about this.
There was no reason to declare a variable for disabledReason, assign it inside the "if binding.GetDisabledReason != nil" statement, and then check its value again after that if statement. Move all that code inside the first if statement to make the control flow easier to understand.
If a DisabledReason has its AllowFurtherDispatching flag set, it is returned as a ErrKeybindingNotHandled error, instead of shown as a toast right away. This allows gocui to continue to dispatch the keybinding, and we can unwrap the error at the other end (in our global ErrorHandler) and display it then. This allows having keybindings for the same key at the local and global levels, and they will continue to be dispatched even if the first one returns a DisabledReason. It is opt-in, so we only use it for cases where we know that a local and a global handler share the same (default) keybinding.
Previously we would call pullFiles() from the pick() handler if we were not in a rebase, assuming that the default keybinding for both is "p". This needn't be the case of course, if the user has remapped one or the other. The consequence of this was that swapping the keybindings for "pullFiles" and "pushFiles" would work in all panels except the Commits panel (unless "pick" was also remapped in the same way). Fix this by using the new AllowFurtherDispatching mechanism of DisabledReasons to pass the keybinding on to the next handler.
…esseduffield#4617) - **PR Description** Improve the dispatching of key bindings so that remapping "pullFiles" to a different key works correctly in the Commits panel. Fixes jesseduffield#4614.
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 PR contains changes from a range of commits from the original repository.
Commit Range:
946f5f1..aa331e5
Files Changed: 25 (22 programming files)
Programming Ratio: 88.0%
Commits included:
... and 5 more commits