1
0
mirror of https://github.com/jesseduffield/lazygit.git synced 2025-07-03 00:57:52 +02:00

6556 Commits

Author SHA1 Message Date
91d8c25183 Fix applying custom patches to a dirty working tree (#4674)
- **PR Description**

Applying or reverting a custom patch when one of the files contained in
the patch had unstaged modifications in the working tree would fail with
the confusing error message "does not match index", regardless of
whether those modifications conflicted with the patch or not. You would
expect this to just work if there are no conflicts, or to get the usual
conflict markers if there are. It was possible to work around this by
manually staging those files, but few people knew about this. Fix this
by staging the files (after asking for confirmation).

Also, fix a minor problem where an auto-stash for the "move patch to
index" command was forgotten to be dropped.
2025-07-02 16:32:32 +02:00
3df894ec92 Stage affected unstaged files when applying or reverting a patch
Unlike moving a patch to the index, applying or reverting a patch didn't
auto-stash, which means that applying a patch when there's a modified (but
unstaged) file in the working tree would error out with the message "error:
file1: does not match index", regardless of whether those modifications conflict
with the patch or not.

To fix this, we *could* add auto-stashing like we do for the "move patch to
index" command. However, in this case we rather simply stage the affected files
(after asking for confirmation). This has a few advantages:

- it only changes the staging state of those files that are contained in the
patch (whereas auto-stashing always changes all files to unstaged)
- it doesn't unnecessarily show a confirmation if none of the modified files are
affected by the patch
- if the patch conflicts with the modified files, the conflicts were "backwards"
("ours" was the patch, "theirs" the modified file); it is more logical if "ours"
is the current state of the file, and "theirs" is the patch.

It's a little unfortunate that the behavior isn't exactly the same as for "move
patch to index", but for that one we do need the auto-stash because of the
rebase that runs behind the scenes.
2025-07-02 16:19:06 +02:00
c440a208a6 Add tests for applying a patch when there's a modified file
The tests show that this currently fails with the confusing error message "does
not match index", regardless of whether the patch conflicts with the
modifications or not. We'll improve this in the next commit.

I don't bother adding tests for reverting a patch, as the code is basically the
same as for apply.
2025-07-02 16:19:06 +02:00
32bd9e6029 Drop stash when successfully unstashing files after moving patch to index 2025-07-02 16:19:06 +02:00
823aa640b9 Add test for moving patch to index when there's a modified file
This is functionality that works already, we only add the test for more complete
test coverage. However, there's a detail problem, and the test demonstrates
this: we keep the stash even if there was no conflict. We'll fix this next.
2025-07-02 16:19:06 +02:00
00d043d743 Cleanup: implement AllFilesInPatch using lo.Keys
Curiously, the function was never called so far, but we're going to use it later
in this branch.
2025-07-02 16:19:06 +02:00
eebc39d3e9 Show stash name for selected stash (#4673)
- **PR Description**

In the Stash panel, show information about the selected stash above the
diff of the stash in the main view. This is useful for stash entries
with very long names that are not fully visible in the Stash panel.

Fixes #4662.
2025-07-02 16:18:11 +02:00
92c9eb614f Show stash title in main view for selected stash entry 2025-07-02 16:15:19 +02:00
ef16867ff1 Cleanup: add NewRunPtyTaskWithPrefix funxtion instead of setting Prefix manually
This is consistent with NewRunCommandTaskWithPrefix.
2025-07-02 16:15:19 +02:00
edcfce22f0 Change Refresh to not return an error (#4680)
- **PR Description**

Refresh is one of those functions that shouldn't require error handling
(similar to triggering a redraw of the UI, see
https://github.com/jesseduffield/lazygit/issues/3887).
2025-07-02 16:14:11 +02:00
c87661dbee Use async refresh rather than manual OnWorker call
This is exactly what async refresh is for.
2025-07-02 16:10:04 +02:00
d82852a909 Change Refresh to not return an error
Refresh is one of those functions that shouldn't require error handling (similar
to triggering a redraw of the UI, see
https://github.com/jesseduffield/lazygit/issues/3887).

As far as I see, the only reason why Refresh can currently return an error is
that the Then function returns one. The actual refresh errors, e.g. from the git
calls that are made to fetch data, are already logged and swallowed. Most of the
Then functions do only UI stuff such as selecting a list item, and always return
nil; there's only one that can return an error (updating the rebase todo file in
LocalCommitsController.startInteractiveRebaseWithEdit); it's not a critical
error if this fails, it is only used for setting rebase todo items to "edit"
when you start an interactive rebase by pressing 'e' on a range selection of
commits. We simply log this error instead of returning it.
2025-07-02 16:09:42 +02:00
2b1f150129 Some code cleanups to the "discard file changes from commit" feature (#4679)
- **PR Description**

I ran into these issues while reading the code.
2025-07-02 16:02:58 +02:00
5be97c6145 Remove another unnecessary refresh
This was added after this PR comment:
https://github.com/jesseduffield/lazygit/pull/3276#discussion_r1469077611

> Can we do a refresh after this reset so that the screen shows that the patch
> has been cancelled? That way, if we cancel on the next popup, the screen will
> be in a valid state.

I don't understand what "cancel on the next popup" means; there is no further
popup after this code.
2025-07-02 15:58:03 +02:00
80e20417a8 Remove unnecessary refresh
CheckMergeOrRebase already calls Refresh.
2025-07-02 15:58:03 +02:00
ee62878e6b Cleanup: remove pointless error handling
ForEachFile can't possibly return an error if the passed function doesn't return
one.
2025-07-02 15:47:48 +02:00
2a5970265d Fix formatting of a keyboard shortcut in the README.md (#4678)
- **PR Description**

This will format the `z` keyboard shortcut reference in this text in the
same way as all other keyboard shortcuts in the README.md file.
2025-07-02 15:28:48 +02:00
d60a843c23 Fix formatting of a keyboard shortcut in the README.md
This will format the `z` keyboard shortcut reference in this text in the
same way as all other keyboard shortcuts in the README.md file.
2025-07-02 15:00:23 +02:00
36388e58b9 Update linter (#4671)
- Update the golangci-lint configuration to use the latest version
(2.2.1)
- Enable a few more linter checks
- Improve the VS Code configuration so that we don't get spurious linter
warnings that wouldn't also show up on CI
- Provide a way to run the exact same golangci-lint version locally that
we use on CI. This is useful in case the globally installed version is a
newer one which emits more warnings.
2025-07-01 11:08:24 +02:00
ca05a2ccea Enable revive linter, and fix a bunch of warnings
I took the set of enabled checks from revive's recommended configuration [1],
and removed some that I didn't like. There might be other useful checks in
revive that we might want to enable, but this is a nice improvement already.

The bulk of the changes here are removing unnecessary else statements after
returns, but there are a few others too.

[1] https://github.com/mgechev/revive?tab=readme-ov-file#recommended-configuration
2025-06-30 19:13:20 +02:00
7aa426fa71 Enable errorlint linter, and fix warnings 2025-06-30 18:30:11 +02:00
0471dbaa84 Enable intrange linter, and fix warnings 2025-06-30 18:30:11 +02:00
1e92d8b7f3 Enable nolintlint linter, and fix warnings 2025-06-30 18:30:11 +02:00
d9e299c1df Update VS Code settings to enable staticcheck linter
... and configure it to run the same checks as golangci-lint.

It may seem redundant to have two linter checks enabled; however, there are
reasons to have both. golangci-lint is what we are running on CI, and it has a
lot more linters than gopls, so we want to run it locally too to get the same
coverage. The linter that is built into gopls is only staticcheck, so that's
redundant; but it has the advantage that the warnings appear a bit faster
(golangci-lint runs only on save, and with a bit of delay), and in particular it
provides quick fixes for some of the checks, which is quite convenient.
2025-06-30 18:30:11 +02:00
9b54dc0b28 Update VS Code settings to use golangci-lint v2
We configure it to call the same binary that the new lint script also uses (see
beginning of the branch).
2025-06-30 18:30:11 +02:00
c4de94cff0 Update .golangci.yml to use version 2
The config file was migrated using `golangci-lint migrate`, and then edited by
hand to disable a few checks that we don't want.
2025-06-30 18:30:11 +02:00
92093ce56a Fix warning QF1003: could use tagged switch 2025-06-30 18:30:11 +02:00
c7d0aaa786 Fix warning QF1004: could use strings.ReplaceAll instead 2025-06-30 18:30:11 +02:00
4604227238 Make stashEntryFromLine a free-standing function
It doesn't use the receiver at all, so doesn't have to be a method.

This fixes ST1016: methods on the same type should have the same receiver name.
2025-06-30 18:30:11 +02:00
b7aecf5f17 Fix warning ST1016: methods on the same type should have the same receiver name 2025-06-30 18:30:11 +02:00
8c574f888c Fix warning ST1016: methods on the same type should have the same receiver name
Most methods use gui as a receiver name (120 of them), so switch the few that
use self over to that too.
2025-06-30 18:30:11 +02:00
7ebf5fff0f Provide a script to lint the whole working copy, and update make lint to use it
The script expects a golangci-lint binary in .bin; this makes it possible to
install the exact same version that also runs on CI.
2025-06-30 18:30:11 +02:00
4439531906 Show annotation information for selected tag (#4663)
- **PR Description**

In the Tags panel, show information about the selected tag above the
commit log. This is mostly useful for annotated tags.

Fixes #4659.
2025-06-30 16:14:20 +02:00
e5b09f34e0 Show tag information for selected tag 2025-06-30 16:12:33 +02:00
b12b1040c3 Add IsAnnotated field to models.Tag struct 2025-06-30 16:12:33 +02:00
718cbdb48c Fix branch head icon appearing at head commit when a remote or tag exists with the same name as the current branch (#4669)
- **PR Description**

Fix the problem that if the `rebase.updateRefs` git config is on, a
branch icon would appear in the commits list for the head commit as soon
as a remote or tag exists whose name is the same as the name of the
current branch.
2025-06-30 16:12:09 +02:00
03abdfcfe2 Fix the CurrentBranchName function
The function would return "head/branchname" when there was either a tag or a
remote with the same name.

While fixing this we slightly change the semantic of the function (and of
determineCheckedOutBranchName, which calls it): for a detached head it now
returns an empty string rather than the commit hash. I actually think this is
better.
2025-06-30 16:08:03 +02:00
f95ac6780f Cleanup: turn around error condition
It is a common go convention for the "happy path" to be as little indented as
possible.
2025-06-30 16:08:03 +02:00
61815c10e7 Add a test showing undesired branch icon at head commit
The icon will appear when there's a tag with the same name as the current branch
(that's what we're testing here), or even when there's a remote with the same
name. I'm not adding a test for this latter case, but this was actually how I
discovered the issue.
2025-06-30 16:08:03 +02:00
7a8937279a Bump github.com/cloudflare/circl from 1.6.0 to 1.6.1 (#4633)
Bumps [github.com/cloudflare/circl](https://github.com/cloudflare/circl)
from 1.6.0 to 1.6.1.
2025-06-30 16:07:34 +02:00
f07c08a071 Bump github.com/cloudflare/circl from 1.6.0 to 1.6.1
Bumps [github.com/cloudflare/circl](https://github.com/cloudflare/circl) from 1.6.0 to 1.6.1.
- [Release notes](https://github.com/cloudflare/circl/releases)
- [Commits](https://github.com/cloudflare/circl/compare/v1.6.0...v1.6.1)

---
updated-dependencies:
- dependency-name: github.com/cloudflare/circl
  dependency-version: 1.6.1
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
2025-06-30 14:00:23 +00:00
75ee875194 Show GPG error before entering commit editor when rewording non-latest commits (#4660)
- **PR Description**

When GPG signing is enabled but overrideGpg is false, attempting to
reword a non-latest commit would show the "Feature not vailable for
users using GPG" error only after the user had already entered the
commit message.

Now the error is displayed immediately when attempting to start the
reword operation, before opening the editor.

Closes #4611
2025-06-30 08:40:42 +02:00
9e05e4d810 fix: show GPG error before entering commit editor
Closes #4611
2025-06-30 08:35:52 +02:00
ef6f96bda3 Add credential prompts for PKCS11-based SSH keys (#4646)
- **PR Description**
Similar to #2239, add credential prompts for PKCS11-based SSH keys.
OpenSSH code reference is
[here](2827b6ac30/ssh-pkcs11.c (L263)).
2025-06-20 08:26:01 +02:00
b5c2524d75 Add credential prompts for PKCS11-based SSH keys 2025-06-20 08:23:59 +02:00
80887f5791 Fix DEFAULT_REMOTE_ICON character code (#4653)
Unicode characters with code longer than 4 digits should be written as
`\Uffffffff` (8 digits)

Fixes #4652
2025-06-20 08:22:15 +02:00
b5c284db39 Fix DEFAULT_REMOTE_ICON character code
Unicode characters with code longer than 4 digits should be written as
`\Uffffffff` (8 digits)

Fixes #4652
2025-06-20 00:03:53 +02:00
159efdef9f Fix moving a custom patch from the very first commit of the history to a later commit (#4631)
- **PR Description**

Moving a custom patch from the very first commit of the history to a
later commit would crash with an index-out-of-range error.

I double-checked that all other callers of
PrepareInteractiveRebaseCommand already call getBaseHashOrRoot, so this
was the only one that was broken.

I decided not to add a test for this as the scenario is not a very
common one.

Fixes #4624.
2025-06-19 18:46:28 +02:00
206283d1f7 Fix moving a custom patch from the very first commit of the history to a later commit
This would crash with an index-out-of-range error.

I double-checked that all other callers of PrepareInteractiveRebaseCommand
already call getBaseHashOrRoot, so this was the only one that was broken.

I decided not to add a test for this as the scenario is not a very common one.
2025-06-19 18:43:17 +02:00
ec0f4d242e Instantiate mutexes by value (#4632)
- **PR Description**

Here's a minor cleanup: instantiate mutexes by value so that they don't
have to be initialized explicitly. It is always preferable for structs
to have a valid zero value, and this is one small step in that
direction.

I read this recommendation in the [Uber style
guide](https://github.com/uber-go/guide/blob/master/style.md#zero-value-mutexes-are-valid),
and it makes a lot of sense to me. I find most of the rest of this style
guide to be a very good read, too.
2025-06-19 18:42:56 +02:00