Skip to content

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
wants to merge 15 commits into
base: feature-base-2
Choose a base branch
from

Conversation

yashuatla
Copy link
Owner

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:

stefanhaller and others added 15 commits June 1, 2025 14:38
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants