### PR Description
This is similar to using lazygit's `Git.Paging.ExternalDiffCommand`
config, except that the command is configured in git. This can be done
either with git's `diff.external` config, or through `.gitattributes`,
so it gives a bit more flexibility.
We could consider removing the `Git.Paging.ExternalDiffCommand` config
now, because its functionality is covered by the new config. I decided
to keep it though, because I don't want to make this a breaking change,
and also because some users might want to have the external diff command
only in lazygit but not on the command line.
This is similar to using lazygit's Git.Paging.ExternalDiffCommand config, except
that the command is configured in git. This can be done either with git's
`diff.external` config, or through .gitattributes, so it gives a bit more
flexibility.
### PR Description
Many people don't understand what this means, which is apparent from the
amount of issues that got filed because of this. Let's get rid of it to
avoid this confusion. People will have to configure their pager twice if
they want to use it both on the command line and in lazygit, which I
think is not a big deal.
See
[here](https://github.com/jesseduffield/lazygit/issues/3704#issuecomment-2330772344)
for more rationale.
Closes#3704.
Many people don't understand what this means, which is apparent from the amount
of issues that got filed because of this. Let's get rid of it to avoid this
confusion. People will have to configure their pager twice if they want to use
it both on the command line and in lazygit, which I think is not a big deal.
### PR Description
When we added support for using external diff commands as pagers (mainly
to support difftastic as a pager) in #2868, we only supported this in
the files and commits panels, but not in the stashes panel. This was
forgotten in 6266e19623.
## **PR Description**
- Currently, `check-required-label` only runs when commits are added to
a PR, even if a maintainer has added labels, so the CI status remains
red until a commit is pushed after labels are added by a maintainer.
- I updated the workflows to run `check-required-label` only on label
events(add/remove) or open PR event.
- This will make PR status updates more accurate, so authors will be
able to see that tests and lint are passing by just checking the PR
status, and maintainers will easily know if the PR is ready for review.
## **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
### 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.
The old link was broken, it would have to be "Formula/l/lazygit.rb" instead of
"Formula/lazygit.rb".
However, I don't find it very useful to link to the raw formula file, so I
decided to change the link to point to the homebrew web page for lazygit.
When showing a confirmation whose text ends with a line feed, we would
make the popup panel one line less tall than it needs to be, so it would
show a scroll bar. One example where this occurred is the very first
popup that users ever see (the "seriously you rock" message for new
users); that's a pretty bad first impression.
This happens because our code to suppress trailing newlines in views
doesn't work for styled text, and the text in confirmations is bold.
This code checks if the last character of the text is a line feed, and
in this case it isn't; the escape sequence for turning bold off comes
after it.
We should really fix this by improving that mechanism, but this would
require some tricky logic, so as a quick fix, trim trailing (and
leading) linefeeds from the text that we display in a confirmation,
before making it bold.
When showing a confirmation whose text ended with a line feed, we would make the
popup panel one line less tall than it needs to be, so it would show a scroll
bar. One example where this occurred is the very first popup that users ever see
(the "seriously you rock" message for new users); that's a pretty bad first
impression.
This happens because our code to suppress trailing newlines in views doesn't
work for styled text, and the text in confirmations is bold. This code checks if
the last character of the text is a line feed, and in this case it isn't; the
escape sequence for turning bold off comes after it.
We should really fix this by improving that mechanism, but this would require
some tricky logic, so as a quick fix, trim trailing (and leading) linefeeds from
the text that we display in a confirmation, before making it bold.
It is being auto-bumped by homebrew, like most formulae these days, so
no reason for us to do that explicitly; and it actually fails with an
error message, so stop trying.
It is being auto-bumped by homebrew, like most formulae these days, so no reason
for us to do that explicitly; and it actually fails with an error message, so
stop trying.
In 3a9dbf7341 we created a global /tmp/lazygit/ folder that contains
the temp directories of each running instance, to avoid polluting /tmp
with multiple folders. The problem with that approach was that the
folder was created with 700 permissions, so if multiple users were using
lazygit on the same machine (e.g. a server), all users except the first
one would get fatal errors on startup.
Fix this by creating temp folders containing the user's uid.
Fixes#4793.
In 3a9dbf7341 we created a global /tmp/lazygit/ folder that contains the temp
directories of each running instance, to avoid polluting /tmp with multiple
folders. The problem with that approach was that the folder was created with 700
permissions, so if multiple users were using lazygit on the same machine (e.g. a
server), all users except the first one would get fatal errors on startup.
Fix this by creating temp folders containing the user's uid.
After discussion from the following PR (
https://github.com/jesseduffield/lazygit/pull/4362 ) I have finally
found time to make a PR to update the Fedora section of the README.md
file. I actually use those instructions myself from few different Fedora
and Amazon Linux 2023 machines.
Here is an example of installing lazygit from the Copr:
```
» sudo dnf install lazygit
Updating and loading repositories:
Repositories loaded.
Package Arch Version Repository Size
Installing:
lazygit x86_64 0.48.0-1.fc41 copr:copr.fedorainfracloud.org:dejan:lazygit 21.5 MiB
Transaction Summary:
Installing: 1 package
Total size of inbound packages is 6 MiB. Need to download 6 MiB.
After this operation, 22 MiB extra will be used (install 22 MiB, remove 0 B).
Is this ok [y/N]: y
[1/1] lazygit-0:0.48.0-1.fc41.x86_64 100% | 3.7 MiB/s | 5.7 MiB | 00m02s
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[1/1] Total 100% | 3.7 MiB/s | 5.7 MiB | 00m02s
Running transaction
[1/3] Verify package files 100% | 52.0 B/s | 1.0 B | 00m00s
[2/3] Prepare transaction 100% | 3.0 B/s | 1.0 B | 00m00s
[3/3] Installing lazygit-0:0.48.0-1.fc41.x86_64 100% | 44.9 MiB/s | 21.5 MiB | 00m00s
Complete!
```
- **PR Description**
In #4684 we improved the hunk selection behavior to work on blocks of
changes instead of actual hunks, and I find this so useful that I wanted
to use it by default. In #4685 I added a user config to make hunk
selection the default, but I made it an opt-in config because I was
worried that users might not find out how to switch back to line
selection if needed.
To address this concern, in this PR I add a popup that explains this the
first time the user enters staging; there is also a breaking changes
notice at startup, and we improve the options display at the bottom of
the screen to be clearer about this. Hopefully these measures are enough
to not confuse people.
Closes#4759.
When the useHunkModeInStagingView config is on and you enter the staging view
with hunk selection enabled, it is confusing to see "a: Select hunk" in the
options view at the bottom.
- **PR Description**
Instead of killing git processes when we no longer need them, close
their ptys or output pipes; this makes them terminate more gracefully,
and it avoids the problem of left-over index.lock files that the next
git command chokes on.
To fix the index.lock problem, only the first two commits of the branch
are needed. I decided to go a bit further and add more commits to make
similar changes to other places in the code; these might be considered
more risky than necessary, and we might decide to drop or revert them if
they cause problems. But it does allow us to remove the kill package
dependency altogether.
Fixes#2050.
As we just did for tasks, close their stdout pipe instead. This makes the called
process terminate more gracefully.
This isn't a change that we *need* to make, it's just a bit nicer.
Now that we close a task's stdout pipe when we are done with it, it should
terminate by itself at that point, so there's no longer a need to kill it. This
way, called processes get a chance to terminate gracefully rather than being
killed with SIGKILL; in particular, this allows git to clean up its index.lock
file if it created one.
- Lazygit creates a temp dir at startup, and is supposed to clean it up
after itself; however, this only worked for the main executable, not
when lazygit was spawned as a helper daemon for interactive rebases, so
we would leak a temp dir every time the user pressed `e` or `ctrl-j` or
other similar commands.
- All these temp dirs were created at top level in `/tmp` and thus
pollute it; now we create them inside a `/tmp/lazygit/` folder. This is
no longer quite as important now that the first bug is fixed, but might
still be useful when lazygit crashes, or when running many instances at
once in different terminal tabs.
Resolves#4781.
This is no longer as important now that we fixed the stale, left-over temp dirs
caused by daemon mode, but it could still be helpful in case lazygit crashes, or
if you have many instances of lazygit running.
The function that called us has just created a temp dir, and scheduled a defer
to remove it again; by calling os.Exit we short-cut this defer, and don't clean
up the temp dir. There is no reason to exit here, the calling function will
return after having called us.
- **PR Description**
Previously we would call git merge-base with the upstream branch to
determine where unpushed commits end and pushed commits start, and also
git merge-base with the main branch(es) to see where the merged commits
start. This worked ok in normal cases, but it had two problems:
- when filtering by path or by author, those merge-base commits would
usually not be part of the commit list, so we would miss the point where
we should switch from unpushed to pushed, or from pushed to merged. The
consequence was that in filtering mode, all commit hashes were always
yellow.
- when main was merged into a feature branch, we would color all commits
from that merge on down in green, even ones that are only part of the
feature branch but not main. (See #3796)
To fix these problems, we switch our approach to one where we call git
rev-list with the branch in question, with negative refspecs for the
upstream branch and the main branches, respectively; this gives us the
complete picture of which commits are pushed/unpushed/merged, so it also
works in the cases described above.
And funnily, even though intuitively it feels more expensive, it
actually performs better than the merge-base calls (for normal usage
scenarios at least), so the commit-loading part of refresh is faster now
in general. We are talking about differences like 300ms before, 140ms
after, in some unscientific measurements I took (depends a lot on repo
sizes, branch length, etc.). An exception are degenerate cases like
feature branches with hundreds of thousands of commits, which are slower
now; but I don't think we need to worry about those too much.
Fixes#3796.
Previously we would call git merge-base with the upstream branch to determine
where unpushed commits end and pushed commits start, and also git merge-base
with the main branch(es) to see where the merged commits start. This worked ok
in normal cases, but it had two problems:
- when filtering by path or by author, those merge-base commits would usually
not be part of the commit list, so we would miss the point where we should
switch from unpushed to pushed, or from pushed to merged. The consequence was
that in filtering mode, all commit hashes were always yellow.
- when main was merged into a feature branch, we would color all commits from
that merge on down in green, even ones that are only part of the feature branch
but not main.
To fix these problems, we switch our approach to one where we call git rev-list
with the branch in question, with negative refspecs for the upstream branch and
the main branches, respectively; this gives us the complete picture of which
commits are pushed/unpushed/merged, so it also works in the cases described
above.
And funnily, even though intuitively it feels more expensive, it actually
performs better than the merge-base calls (for normal usage scenarios at least),
so the commit-loading part of refresh is faster now in general. We are talking
about differences like 300ms before, 140ms after, in some unscientific
measurements I took (depends a lot on repo sizes, branch length, etc.). An
exception are degenerate cases like feature branches with hundreds of thousands
of commits, which are slower now; but I don't think we need to worry about those
too much.
This makes it easier to use the full ref in the git merge-base call, which
avoids ambiguities when there's a tag with the same name as the current branch.
This fixes a hash coloring bug in the local commits panel when there's a tag
with the same name as the checked out branch; in this case all commit hashes
that should be yellow were painted as red.
GetMergeBase is always called with a full ref, so it shouldn't need the
ignoringWarnings hack (which is about ignoring warnings coming from ambiguous
refs).
Also, separate stdout and stderr, which would also have solved the problem. We
no longer really need it now, but it's still cleaner.
- **PR Description**
I didn't enable the `showDivergenceFromBaseBranch` config by default yet
(even though I find it very useful) because I'm worried that people
might find the display too noisy. Drawing the divergence information
right-aligned helps reduce that noise a little bit.
- **PR Description**
In the Go 1.21 standard library, a new function has been introduced that
enhances code conciseness and readability. It can be find
[here](https://pkg.go.dev/slices@go1.21.1#Equal).
- **PR Description**
This is very similar to what we did for pressing space in #4386; we
forgot that the "stage all" command has the same issue.
Also, fix two other commands that stage all files under the hood:
- when continuing a rebase after resolving conflicts, we auto-stage all
files, but in this case we never want to include untracked files,
regardless of the filter
- likewise, pressing ctrl-f to find a base commit for fixup stages all
files for convenience, but again, this should only stage files that are
already tracked
Also, fix two other commands that stage all files under the hood:
- when continuing a rebase after resolving conflicts, we auto-stage all files,
but in this case we never want to include untracked files, regardless of the
filter
- likewise, pressing ctrl-f to find a base commit for fixup stages all files for
convenience, but again, this should only stage files that are already tracked
- **PR Description**
This way we don't have to update the text and all translations every
time we bump the version.
Remove the year from the error text, it's cumbersome to update and I
don't find it very important to have in the message.
Also remove the invitation to file an issue; I don't find it very likely
that we are going to relax the minimum git requirement again.
This way we don't have to update the text and all translations every time we
bump the version.
Remove the year from the error text, it's cumbersome to update and I don't find
it very important to have in the message.
Also remove the invitation to file an issue; I don't find it very likely that we
are going to relax the minimum git requirement again.
- **PR Description**
In #4663 we added information in the tags panel about the selected tag
(whether it's annotated etc). Unfortunately this introduced a
performance regression in repositories with many tags, so revert this
and implement the feature in a slightly different way to avoid the
performance hit.
Fixes#4770.
It seems that `git for-each-ref` is a lot slower than `git tag --list` when
there are thousands of tags, so revert back to the previous method, now that we
no longer use the IsAnnotated field.
This reverts commit b12b1040c3.
Storing it in the Tag struct makes loading tags a lot slower when there is a
very large number of tags; so determine it on the fly instead. On my machine,
the additional call takes under 5ms, so it seems we can afford it.
Stefan HallerandGitHub