Codeberg is a Gitea-based git hosting service that uses the same URL
patterns for pull requests and commits. This adds native support so
users don't need to manually configure it.
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
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).
Yadi Abdalhalim
Stefan Haller
Peter Cardenas
github-actions[bot]
Mikhail Akimov
riyueguang
boqishan
dependabot[bot]
Karol Zwolak