This changes not only how we store modifiers (inside of Key instead of passing
it separately), but also how we parse keybinding strings: it supports all
combinations of modifiers now (if the terminal supports it, that is).
An uppercase letter is not valid with ctrl, and only works because we lowercase
the string before parsing it. This will change later in this branch when we
start supporting bindings like <c-s-r>.
Refactor code to introduce a Key type in gocui that bundles the keyName
and a rune, so that we don't have to pass these around separately
everywhere.
This, and updating tcell to v3 lays the ground for supporting more
keybindings in terminals that support the CSIu keyboard protocol.
This bundles the keyName and a rune, so that we don't have to pass these around
separately everywhere. This should make it easier to swap out the rune for a
string when we upgrade to tcell v3.
Over the past few months or even years, [Jesse's gocui
fork](https://github.com/jesseduffield/gocui) has become more and more
tied to lazygit; I have repeatedly made API-breaking changes to it
without caring much about what this means for other clients like
lazydocker or lazynpm (and Jesse was ok with that).
Given that situation, it no longer makes much sense to maintain it in a
standalone repo, so copy it into lazygit; this will greatly reduce the
friction of making changes to it. If/when the time comes to update those
other clients to also benefit from the improvements we make here, we can
always copy the files back to the gocui fork and resume it there.
I copied all files except dot files (.github and .gitignore), the _examples
folder, and go.mod/go.sum.
At some point we may want to copy the files back to the gocui repo when other
clients (e.g. lazydocker) want to use the newer versions of them.
### PR Description
Instead of manually figuring out how much ahead each branch is from it's
upstream branch, use [for-each-ref
ahead-behind](https://git-scm.com/docs/git-for-each-ref/2.41.0#Documentation/git-for-each-ref.txt-ahead-behindcommittish)
if supported by the git binary.
On my Windows machine, using the lazygit repo with all 61 branches
created locally, it goes from ~8.5s to ~200ms.
It was also able to find a base branch for `assets` which the previous
iteration did not.
Fixes#5532
Bumps [golang.org/x/sys](https://github.com/golang/sys) from 0.42.0 to
0.43.0.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="f33a730cd0"><code>f33a730</code></a>
windows: support nil security descriptor on GetNamedSecurityInfo</li>
<li><a
href="493d172598"><code>493d172</code></a>
cpu: add runtime import in cpu_darwin_arm64_other.go</li>
<li><a
href="2c2be756b9"><code>2c2be75</code></a>
windows: use syscall.SyscallN in Proc.Call</li>
<li><a
href="a76ec62d6c"><code>a76ec62</code></a>
cpu: roll back "use IsProcessorFeaturePresent to calculate ARM64 on
windows"</li>
<li>See full diff in <a
href="https://github.com/golang/sys/compare/v0.42.0...v0.43.0">compare
view</a></li>
</ul>
</details>
<br />
Bumps [actions/github-script](https://github.com/actions/github-script)
from 8 to 9.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/actions/github-script/releases">actions/github-script's
releases</a>.</em></p>
<blockquote>
<h2>v9.0.0</h2>
<p><strong>New features:</strong></p>
<ul>
<li><strong><code>getOctokit</code> factory function</strong> —
Available directly in the script context. Create additional
authenticated Octokit clients with different tokens for multi-token
workflows, GitHub App tokens, and cross-org access. See <a
href="https://github.com/actions/github-script#creating-additional-clients-with-getoctokit">Creating
additional clients with <code>getOctokit</code></a> for details and
examples.</li>
<li><strong>Orchestration ID in user-agent</strong> — The
<code>ACTIONS_ORCHESTRATION_ID</code> environment variable is
automatically appended to the user-agent string for request
tracing.</li>
</ul>
<p><strong>Breaking changes:</strong></p>
<ul>
<li><strong><code>require('@actions/github')</code> no longer works in
scripts.</strong> The upgrade to <code>@actions/github</code> v9
(ESM-only) means <code>require('@actions/github')</code> will fail at
runtime. If you previously used patterns like <code>const { getOctokit }
= require('@actions/github')</code> to create secondary clients, use the
new injected <code>getOctokit</code> function instead — it's available
directly in the script context with no imports needed.</li>
<li><code>getOctokit</code> is now an injected function parameter.
Scripts that declare <code>const getOctokit = ...</code> or <code>let
getOctokit = ...</code> will get a <code>SyntaxError</code> because
JavaScript does not allow <code>const</code>/<code>let</code>
redeclaration of function parameters. Use the injected
<code>getOctokit</code> directly, or use <code>var getOctokit =
...</code> if you need to redeclare it.</li>
<li>If your script accesses other <code>@actions/github</code> internals
beyond the standard <code>github</code>/<code>octokit</code> client, you
may need to update those references for v9 compatibility.</li>
</ul>
<h2>What's Changed</h2>
<ul>
<li>Add ACTIONS_ORCHESTRATION_ID to user-agent string by <a
href="https://github.com/Copilot"><code>@Copilot</code></a> in <a
href="https://redirect.github.com/actions/github-script/pull/695">actions/github-script#695</a></li>
<li>ci: use deployment: false for integration test environments by <a
href="https://github.com/salmanmkc"><code>@salmanmkc</code></a> in <a
href="https://redirect.github.com/actions/github-script/pull/712">actions/github-script#712</a></li>
<li>feat!: add getOctokit to script context, upgrade
<code>@actions/github</code> v9, <code>@octokit/core</code> v7, and
related packages by <a
href="https://github.com/salmanmkc"><code>@salmanmkc</code></a> in <a
href="https://redirect.github.com/actions/github-script/pull/700">actions/github-script#700</a></li>
</ul>
<h2>New Contributors</h2>
<ul>
<li><a href="https://github.com/Copilot"><code>@Copilot</code></a> made
their first contribution in <a
href="https://redirect.github.com/actions/github-script/pull/695">actions/github-script#695</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/actions/github-script/compare/v8.0.0...v9.0.0">https://github.com/actions/github-script/compare/v8.0.0...v9.0.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="3a2844b7e9"><code>3a2844b</code></a>
Merge pull request <a
href="https://redirect.github.com/actions/github-script/issues/700">#700</a>
from actions/salmanmkc/expose-getoctokit + prepare re...</li>
<li><a
href="ca10bbdd1a"><code>ca10bbd</code></a>
fix: use <code>@octokit/core/</code>types import for v7
compatibility</li>
<li><a
href="86e48e20ac"><code>86e48e2</code></a>
merge: incorporate main branch changes</li>
<li><a
href="c1084728b5"><code>c108472</code></a>
chore: rebuild dist for v9 upgrade and getOctokit factory</li>
<li><a
href="afff112e4f"><code>afff112</code></a>
Merge pull request <a
href="https://redirect.github.com/actions/github-script/issues/712">#712</a>
from actions/salmanmkc/deployment-false + fix user-ag...</li>
<li><a
href="ff8117e5b7"><code>ff8117e</code></a>
ci: fix user-agent test to handle orchestration ID</li>
<li><a
href="81c6b78760"><code>81c6b78</code></a>
ci: use deployment: false to suppress deployment noise from integration
tests</li>
<li><a
href="3953caf885"><code>3953caf</code></a>
docs: update README examples from <a
href="https://github.com/v8"><code>@v8</code></a> to <a
href="https://github.com/v9"><code>@v9</code></a>, add getOctokit docs
and v9 brea...</li>
<li><a
href="c17d55b90d"><code>c17d55b</code></a>
ci: add getOctokit integration test job</li>
<li><a
href="a047196d9a"><code>a047196</code></a>
test: add getOctokit integration tests via callAsyncFunction</li>
<li>Additional commits viewable in <a
href="https://github.com/actions/github-script/compare/v8...v9">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
[//]: # (dependabot-start)
⚠️ **Dependabot is rebasing this PR** ⚠️
Rebasing might not happen immediately, so don't worry if this takes some
time.
Note: if you make any changes to this PR yourself, they will take
precedence over the rebase.
---
[//]: # (dependabot-end)
Bumps [dario.cat/mergo](https://github.com/imdario/mergo) from 1.0.1 to
1.0.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/imdario/mergo/releases">dario.cat/mergo's
releases</a>.</em></p>
<blockquote>
<h2>v1.0.2</h2>
<h2>What's Changed</h2>
<ul>
<li>Drops <code>gopkg.in/yaml.v3</code>, only used for loading fixtures.
Thanks <a href="https://github.com/trim21"><code>@trim21</code></a> for
bringing to my attention (<a
href="https://redirect.github.com/imdario/mergo/issues/262">#262</a>)
that this library is no longer maintained.</li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/darccio/mergo/compare/v1.0.1...v1.0.2">https://github.com/darccio/mergo/compare/v1.0.1...v1.0.2</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="7b33b2b010"><code>7b33b2b</code></a>
refactor: migrate from YAML to JSON for test data and update related
functions</li>
<li><a
href="229a214867"><code>229a214</code></a>
chore(.well-known): add funding manifest URLs file</li>
<li><a
href="6be20c6d7d"><code>6be20c6</code></a>
chore(SECURITY.md): update supported versions to reflect current
versioning</li>
<li><a
href="9007623e52"><code>9007623</code></a>
chore(README) : remove kubernetes from the list of users</li>
<li><a
href="2b1eb9c67d"><code>2b1eb9c</code></a>
Update FUNDING.yml</li>
<li><a
href="2ceb99467b"><code>2ceb994</code></a>
Create FUNDING.json</li>
<li>See full diff in <a
href="https://github.com/imdario/mergo/compare/v1.0.1...v1.0.2">compare
view</a></li>
</ul>
</details>
<br />
This is so that they look the same no matter what color palette the
terminal is using. (One user complained that the text for the Open state
is barely readable, because they are using a palette that has a very
pale green.)
GitHub uses slightly different colors depending on light vs. dark mode;
fortunately they are very close, so hopefully we can ignore this. I
picked the ones for dark mode here, on the assumption that this is more
common.
Also, not all terminals support true hex colors; for example,
Terminal.app on macOS doesn't, so it maps the colors to the closest ones
in the Xterm-256 palette. This shouldn't be a huge problem, but for some
reason it displays draft PRs as something closer to Cyan than grey, and
I don't understand why.
This is so that they look the same no matter what color palette the terminal is
using. (One user complained that the text for the Open state is barely readable,
because they are using a palette that has a very pale green.)
GitHub uses slightly different colors depending on light vs. dark mode;
fortunately they are very close, so hopefully we can ignore this. I picked the
ones for dark mode here, on the assumption that this is more common.
Also, not all terminals support true hex colors; for example, Terminal.app on
macOS doesn't, so it maps the colors to the closest ones in the Xterm-256
palette. This shouldn't be a huge problem, but for some reason it displays draft
PRs as something closer to Cyan than grey, and I don't understand why.
If the repo has multiple remotes, but only one of them is on Github (the
others might for example point to a self-hosted Critic server or
something like that), lazygit would still present a menu to choose the
remote for pull requests, but it would contain only that single entry.
That's pointless, pick it automatically without prompting.
If the repo has multiple remotes, but only one of them is on Github (the others
might for example point to a self-hosted Critic server or something like that),
lazygit would still present a menu to choose the remote for pull requests, but
it would contain only that single entry. That's pointless, pick it automatically
without prompting.
We add some tests while we're at it; these wouldn't have caught the problem,
because they only test getGithubBaseRemote which already takes the filtered
github remotes. It's still better than not having any tests; the real issue
could only have been caught with an integration test, which we don't bother
adding.
If we used to have a base remote (e.g. because there was only one), but
now we don't (e.g. because the user has added a second one, and we don't
know yet which one is the base), stop showing the cached PRs. This is
especially important in the case that the user cancels the prompt, in
which case we don't have a base remote for the rest of the session, but
would keep showing the (potentially stale) cached PRs forever.
You might ask why we don't retain the previous base remote in the case
that we used to have one but no longer do; this may be possible, but
it's error-prone because the user might have shuffled their remotes
around and changed their names. I don't think it's worth the risk.
If we used to have a base remote (e.g. because there was only one), but now we
don't (e.g. because the user has added a second one, and we don't know yet which
one is the base), stop showing the cached PRs. This is especially important in
the case that the user cancels the prompt, in which case we don't have a base
remote for the rest of the session, but would keep showing the (potentially
stale) cached PRs forever.
