The confirmation used to make sense back when the Open MergeTool command
was its own top-level command; however, that command was changed in
#4889 to open a menu instead, and Open MergeTool is now just a submenu
entry in that menu, so it no longer needs a confirmation.
Fixes#5093.
The confirmation used to make sense back when the Open MergeTool command was its
own top-level command; however, that command was changed in 703f053a7e to open a
menu instead, and Open MergeTool is now just a submenu entry in that menu, so it
no longer needs a confirmation.
### PR Description
Use case: some repositories are cloned with a full SSH alias (without a
user). E.g. in `.ssh/config` you have
```
Host gitlab
HostName gitlab.com
User git
IdentityFile ...
```
and then you clone with `git clone gitlab:foo/bar`
According to the docs, you can add a service to `config.yaml` and it
should work:
```yaml
services:
gitlab: 'gitlab:gitlab.com'
```
But currently it doesn't because lazygit expects all remote URLs to have
a user. This can be fixed by the user by changing the URL to e.g.
`git@gitlab:foo/bar`, but it breaks the user flow and is quite
unexpected.
This PR changes `defaultUrlRegexStrings` and makes the `user@` part of
the remote URL optional. Fixes the issue for Github and Gitlab which use
the default regexes.
Users have filed issues with crash reports that seem to indicate that
the FileTreeViewModel gets swapped out (by a refresh) while a call to
itemsSelected is in progress, iterating over the previous items. Guard
against this by locking the mutex that we already have for this for the
duration of the call.
I don't have a good way of testing whether the fix helps, because the
crashes only occurred very infrequently. Let's just see if the crash
reports stop coming in after we ship this.
Note also that this is only the minimal fix for the crashes that were
reported. Theoretically, the same problem could happen for a key handler
itself, but we never saw reports about that, so we don't bother doing
anything about that yet.
Note also that long-term I envision a different solution to this class
of problems (discussed in
https://github.com/jesseduffield/lazygit/issues/2974), that's why I want
to avoid locking mutexes more than necessary now.
Fixes#3646Fixes#4154Fixes#4301Fixes#5070
Users have filed issues with crash reports that seem to indicate that the
FileTreeViewModel gets swapped out (by a refresh) while a call to itemsSelected
is in progress, iterating over the previous items. Guard against this by locking
the mutex that we already have for this for the duration of the call.
I don't have a good way of testing whether the fix helps, because the crashes
only occurred very infrequently. Let's just see if the crash reports stop coming
in after we ship this.
Note also that this is only the minimal fix for the crashes that were reported.
Theoretically, the same problem could happen for a key handler itself, but we
never saw reports about that, so we don't bother doing anything about that yet.
Note also that long-term I envision a different solution to this class of
problems (discussed in https://github.com/jesseduffield/lazygit/issues/2974),
that's why I want to avoid locking mutexes more than necessary now.
If the ctrl-f command ("Find base commit for fixup") finds multiple
candidates, it lists them all in an error message. Previously they were
listed in random order in the error message, which can be confusing;
it's nicer to see them in the same order in which they appear in the
commit log.
Fixes#5071.
We want to test the order in which the commits are listed in the error message.
For one of the tests the order is already as we want it, but for the other it's
not (we want them to show up in log order). We'll fix this in the next commit.
It is a bit generic, it seems that users sometimes set it for other reasons, and
then they are confused why they don't see anything. Use a more specific name
instead.
The file suggestions list that appears when you choose "Enter path to
filter by" from the Filtering menu was previously implemented by walking
the file system to collect all files, and then filter out the ones that
are git-ignored. This approach had several problems:
- for certain .gitignore configurations there was a bug in the code that
filters out ignored files, causing the list to be empty. See
https://github.com/jesseduffield/lazygit/issues/2642#issuecomment-3554117172
for details.
- the list included files from submodules. While at first glance this
might sound useful, it doesn't work: choosing a file from the list shows
an empty log. Lazygit would have to switch to the submodule first to
show the log, which would be unexpected in the context of the Filtering
dialog, so it's better to not show these files, and require the user to
enter a submodule explicitly before they can filter on a file in it.
- it was rather slow.
This PR improves all these by using a call to `git ls-files` to list the
repositories files.
Here are some rough hand-timed measurements (from opening the Filtering
dialog until the file list shows) for various repos:
| | before | after |
|:--------------------------- | ------:| -------------- |
| lazygit (3'200 files) | ~1s | not measurable |
| my work repo (90'000 files) | 7s | <1s |
| llvm (150'000 files) | 5s | ~1s |
Fixes#2642
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from
0.37.0 to 0.45.0.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="4e0068c009"><code>4e0068c</code></a>
go.mod: update golang.org/x dependencies</li>
<li><a
href="e79546e28b"><code>e79546e</code></a>
ssh: curb GSSAPI DoS risk by limiting number of specified OIDs</li>
<li><a
href="f91f7a7c31"><code>f91f7a7</code></a>
ssh/agent: prevent panic on malformed constraint</li>
<li><a
href="2df4153a03"><code>2df4153</code></a>
acme/autocert: let automatic renewal work with short lifetime certs</li>
<li><a
href="bcf6a849ef"><code>bcf6a84</code></a>
acme: pass context to request</li>
<li><a
href="b4f2b62076"><code>b4f2b62</code></a>
ssh: fix error message on unsupported cipher</li>
<li><a
href="79ec3a51fc"><code>79ec3a5</code></a>
ssh: allow to bind to a hostname in remote forwarding</li>
<li><a
href="122a78f140"><code>122a78f</code></a>
go.mod: update golang.org/x dependencies</li>
<li><a
href="c0531f9c34"><code>c0531f9</code></a>
all: eliminate vet diagnostics</li>
<li><a
href="0997000b45"><code>0997000</code></a>
all: fix some comments</li>
<li>Additional commits viewable in <a
href="https://github.com/golang/crypto/compare/v0.37.0...v0.45.0">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 merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@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)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/jesseduffield/lazygit/network/alerts).
</details>
We move the code to push the branches context into CheckoutRef, this way
it works consistently no matter where we call it from. Previously,
checking out remote branches or tags would switch to the branches view,
but checking out a commit did not.
Note that it now also takes effect for undoing or redoing a checkout,
which may be a bit questionable; but I still think it makes sense for
this, too.
We move the code to push the branches context into CheckoutRef, this way it
works consistently no matter where we call it from. Previously, checking out
remote branches or tags would switch to the branches view, but checking out a
commit did not.
Note that it now also takes effect for undoing or redoing a checkout, which may
be a bit questionable; but I still think it makes sense for this, too.
If background fetching is on (which it is by default), we usually run
the first background fetch right after opening lazygit, which is nice
because it immediately fetches all the stuff that's new. However, when
switching to a different repo from within lazygit (either with the
recent repos menu or by going into or out of a submodule) we didn't do
that, and you'd have to wait for the next regular background fetch to
come along. I'm finding myself pressing `f` in the Files panel to
manually fetch after entering a submodule, and I shouldn't have to do
that.
This PR makes it so that when you switch repos, we trigger a background
fetch immediately (unless the last one for this repo was less than the
auto-fetch interval ago, in which case it's unnecessary).
