We move the selection down by the number of commits that were reverted (to keep
the same commits selected). However, this only happens after refreshing, which
has rendered the main view with the wrong commit, so we need to render it again
after moving the selection.
There are many other callers of MoveSelection in LocalCommitsController, but all
of them happen before the refresh. Revert is special because it needs to move
the selection after refreshing, e.g. when reverting the only commit of a branch.
Now that we can use 'k' as a menu item binding (this was fixed in
#5131), use it for the "keep" entry in the merge menu. I don't think
this will be a problem for people's muscle memory, given that this menu
is not encountered every day; and it's simply the better keybinding.
This reverts commit b32b55201e.
Now that we can use 'k' as a menu item binding (this was fixed in #5131), use it
for the "keep" entry in the merge menu. I don't think this will be a problem for
people's muscle memory, given that this menu is not encountered every day; and
it's simply the better keybinding.
This reverts commit b32b55201e.
Previously they would be shown as keybindings in the menu, but they
didn't work because their builtin functionality (select next/prev line,
scroll view left/right) would take precedence.
This will allow us to revert #4934; doing that in a separate PR, see
#5132.
This is not really super important because we are very unlikely to assign a key
such as esc or up/down to a menu item. However, users might do this in a custom
commands menu, and in that case it is important that the builtin keys still
work; or they might remap those builtin commands to other keys, in which case
they might conflict with single-letter keys in normal menus.
The test shows two problems: a <down> keybinding is not removed from a menu item
(the 'y' binding is removed though, which is correct), and keybindings such as
'j' and 'H' don't work. We will fix both of these separately in the following
commits.
Thank you for an awesome tool. I wanted to add support for codeberg.
Tested locally that opening pull-request works
### PR Description
Codeberg is a Gitea-based git hosting service that uses the same URL
patterns for pull requests and commits but differs on its hostname
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
Stefan Haller
Karl Wikström
Yadi Abdalhalim
Peter Cardenas
github-actions[bot]
Mikhail Akimov
riyueguang
boqishan