## **PR Description**
Sometimes, I want to copy the error message to clipboard to search
google or ask to LLM about the error message.
So I added CopyToClipboard command to `ConfirmationController` and I
have confirmed that this command copies the content of the window to the
clipboard.
This was needed in an earlier version of the test, when we asserted the file
content in a more complicated way. It should have been removed in caca62b89e.
## ✨ Add Ctrl+Z suspend support for LazyGit on Unix-like systems
### 📝 Summary
This PR adds support for suspending LazyGit when the user presses
`Ctrl+Z`, making it behave like common CLI tools (e.g., Vim, less,
htop):
* Pressing `Ctrl+Z` sends a `SIGTSTP` signal to suspend LazyGit.
* After resuming with `fg`, LazyGit redraws and continues working
without hanging.
* During suspension, background routines are paused to avoid running
while LazyGit is stopped.
### ✅ Motivation
Make LazyGit feel more native on Unix-like systems by supporting
standard terminal suspend/resume (Ctrl+Z / fg) behavior.
Closes#3906
This frees up ctrl-z for suspend. Hopefully, redo is not such a frequently used
operation that the change annoys people.
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
### PR Description
- For popup windows, the status bar would show `Confirm: <enter> |
Close/Cancel: <esc> | Cancel: <esc>`. Omit the second `<esc>`.
- Don't show the `<esc>` binding in other views when it doesn't do
anything.
- Change the text of the `<esc>` label to show what it does, based on
context. This is very helpful because esc can cancel all sorts of
things, and if several of these things are active at once, it is not
obvious which one will be cancelled first.
Supersedes #4808.
In some cases we set a disabled reason but leave the text empty, so that we
don't get an error toast when the item is invoked. In such a case it looks
awkward if there is a tooltip showing "Disabled: " with no following text.
For many menus, just "Close" is fine, but some menus act more like confirmations
(e.g. the menu that appears when you cherry-pick and get conflicts); in this
case, it's good to make it more obvious that hitting esc cancels the whole
thing.
Dismissing a range selection is handled by the global escape handler for all
list views, but not for the staging and patch building views, so we need to make
the esc description dynamic for these, too.
The main reason for this is that sometimes the escape key is handled by a local
binding, in which case it appears before the '?' binding in the options status
bar, and other times it is handled by the global controller, in which case it
appeared after. Moving it to before the keybindings menu handler makes it appear
before '?' in both cases.
Also, if the window is too narrow to show all keybindings, the ones that don't
fit will be truncated, and in this case it is more important to show the esc
binding because of its context sensitivity.
This also moves the esc entry up a few positions in the keybindings menu, but I
don't think this matters much.
Sometimes there is a local and a global keybinding for the same key; if both are
configured to be shown in the options map, we should only show the local one
because it takes precedence. This happens for example for <esc> in a popup, or
for <esc> in the focused main view.
Note that this is also a problem in the keybindings menu, and we don't solve
that here.
It's maybe not totally obvious, so let's show it.
Esc now appears twice in the status bar, because the global controller also
appends its generic "Cancel". We'll fix this in the next commit.
**PR Description**
This PR adds support for parsing **legacy Azure DevOps SSH remotes**
that use the
`vs-ssh.visualstudio.com` host, which is still common in older
repositories or corporate setups.
This PR fixes issue #2667.
Previously, even if users mapped this host to the Azure DevOps provider
via
`configServiceDomains`, URL generation failed with:
```
Failed to parse repo information from url
```
because the Azure DevOps `ServiceDefinition` regex set did not include
this SSH format.
### Changes
- Added a new regex to `azdoServiceDef.regexStrings` to match:
```
git@vs-ssh.visualstudio.com:v3/<org>/<project>/<repo>
```
- This allows `getRepoURLFromRemoteURL` to correctly extract `org`,
`project`, and `repo`
for these remotes.
- Added a test case to `TestGetPullRequestURL` verifying that mapping
`vs-ssh.visualstudio.com` → `azuredevops:dev.azure.com` produces the
correct PR URL.
### Example
With this config:
```yaml
services:
'vs-ssh.visualstudio.com': 'azuredevops:dev.azure.com'
```
and remote:
```
git@vs-ssh.visualstudio.com:v3/myorg/myproject/myrepo
```
`GetPullRequestURL("feature/new", "")` now returns:
```
https://dev.azure.com/myorg/myproject/_git/myrepo/pullrequestcreate?sourceRef=feature%2Fnew
```
### Why
- Many users still have remotes in this legacy format.
- This change is **backward-compatible** and does not affect existing
supported remotes.
- It unblocks URL generation for PRs and commits without requiring users
to change their remotes.
- Fixes#2667
An example for this can be seen in the next commit.
We make this a setter rather than an added constructor argument so that we don't
have to change all those contexts that don't want to make use of this.
This assertion didn't test anything useful, given that the filtered view already
has two lines. This should have been adapted in 9f0b4d0000 when we added
section headers while filtering.
- **PR Description**
We didn't take the worktree icon into account properly, so the
divergence indication was offset to the left by two characters in this
case.
I haven't used worktrees myself so far, so I didn't notice this before.
- **PR Description**
This PR adds to the documentation a way of installation using
[gah](https://github.com/marverix/gah/).
> gah is an GitHub Releases app installer, that does not require sudo.
It is a simple bash script that downloads the latest release of an app
from GitHub and installs it in `~/.local/bin`. It is designed to be used
with apps that are distributed as a single binary file.
## **PR Description**
The below error message is shown when executing `make format` when
`test/_results/demo/worktree_create_from_branches/actual/repo/src/shims.go`
exists (maybe executing integration test produces this file?).
```sh
$ make format
gofumpt -l -w .
test/_results/demo/worktree_create_from_branches/actual/repo/src/shims.go:1:20: expected 'package', found 'EOF'
make: *** [format] Error 2
```
I have confirmed it works without above error when I run `make format`
on this PR's branch.
One reason why git diff can be very slow is when "diff.algorithm =
histogram" is being used. In this case, showing a very long single-file
diff can take seconds to load, and you'll see the "loading..." message
in the main view until we got the first lines of the diff to show.
There's nothing really we can do about this delay; however, when
switching to another, shorter file (or commit) while the "loading..."
message is still showing, this switch should be instantaneous. And it
was before 0.54.0, but we broke this in 0.54.0 with 8d7740a5ac
(#4782); now users have to wait for the slow git diff command to output
more text before the switch occurs. To fix this, don't block waiting for
the process to terminate if we just stopped it.
In addition, improve CPU usage by terminating git processes gracefully
(by sending them a TERM signal); this helps keep CPU usage low when
flicking through several of these huge diffs with "diff.algorithm =
histogram", because it avoids having several git processes running in
the background, calculating expensive diffs that we are never going to
show. Unfortunately this is only possible on Linux and Mac, so Windows
users will have to live with the higher CPU usage. The recommended
workaround is to not use "diff.algorithm = histogram".
Fixes#4798.
The previous commit already fixed the user-visible lag, but there's still a
problem with multiple background git processes consuming resources calculating
diffs that we are never going to show. Improve this by terminating those
processes (by sending them a TERM signal).
Unfortunately this is only possible on Linux and Mac, so Windows users will have
to live with the higher CPU usage. The recommended workaround is to not use
"diff.algorithm = histogram".
One reason why git diff can be very slow is when "diff.algorithm = histogram" is
being used. In this case, showing a very long single-file diff can take seconds
to load, and you'll see the "loading..." message in the main view until we got
the first lines of the diff to show. There's nothing really we can do about this
delay; however, when switching to another, shorter file (or commit) while the
"loading..." message is still showing, this switch should be instantaneous. And
it was before 0.54.0, but we broke this in 0.54.0 with 8d7740a5ac (#4782); now
users have to wait for the slow git diff command to output more text before the
switch occurs.
To fix this, don't block waiting for the process to terminate if we just stopped
it.
Both of these badges have the coloring logic to show stable releases in blue,
and prereleases in orange. The criterion for a prerelease is that the major
version is 0. Now it is debatable whether we consider lazygit "stable", but I
don't feel we are in a preliminary state of the project, working towards the
first final 1.0 release, so I feel blue expresses the state of the project
better.
