Codacy hasn't analysed this repository since April 2026, because status
checks are disabled for it in Codacy's settings. The uploads from CI
still succeed, but the commits never show up in Codacy, and the coverage
badge in the README shows 0%.
We decided not to revive the integration. Remove the upload job and the
two Codacy badges.
If LAZYGIT_GOCOVERDIR is set, run_integration_tests.sh collects the
coverage of the integration tests. Only the lazygit binary writes its
data to that directory, though. The test runner always writes to
/tmp/code_coverage, so the data ends up in two places unless the
variable points there. On CI it always did.
Also, the run fails if the directory doesn't exist yet. With a relative
path, the binary's data goes missing, because the binary runs in the
directory of the test's repo.
Pass the directory to the test runner too, create it if needed, and turn
it into an absolute path.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Go Report Card has shut down. The badge now reads "go report: retired",
and the report page only shows a farewell note. That note recommends
golangci-lint as the replacement, and we already show a badge for it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
CI collected coverage data from the unit and integration tests only for
the Codacy upload. Nothing else reads it.
Remove the coverage flags, the LAZYGIT_GOCOVERDIR env var and the
artifact uploads from the CI workflow. Keep the support for
LAZYGIT_GOCOVERDIR in run_integration_tests.sh and in the integration
test runner, so that we can still measure the coverage of the
integration tests locally.
Remove the step in run_integration_tests.sh that merges the coverage
files, though. It only existed to reduce the number of artifacts to
upload.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Codacy hasn't analysed this repository since April 2026, because status
checks are disabled for it in Codacy's settings. The uploads from CI
still succeed, but the commits never show up in Codacy, and the coverage
badge in the README shows 0%. On Dependabot PRs the upload fails
outright. These runs don't get the CODACY_PROJECT_TOKEN secret.
We decided not to revive the integration. Remove the upload job and the
two Codacy badges.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
With Go 1.27 installed, `just lint` fails with typecheck errors like
"export data version 5 is greater than maximum supported version 4".
The shim builds golangci-lint with the local Go, but v2.12.2 can't read
the export data of Go 1.27's standard library. Support for Go 1.27 came
in v2.13.0.
v2.15.0 still builds with Go 1.26, so linting keeps working there too.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
TestClosingAPipelinesOutputBringsItDown receives the error of
Pipeline.Wait from a channel and ignores it. errcheck v1.30.0 reports
such a receive as an unchecked error. golangci-lint 2.15.0 comes with
this errcheck version, and the next commit bumps to it.
The test ignores the error on purpose. It only checks that Wait returns,
and the error depends on the platform. Make that explicit by discarding
the error in the goroutine, and use the channel only to signal that
Wait has returned.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Releases are run from stefanhaller's fork, but if that fork is not up to
date with jesseduffield's, bad things can happen. Guard against this by
checking that the release.yml file in both is identical.
Also take the go version to build with from the go.mod file in the
branch that is being released from, rather than hard-code it in
release.yml; this could be relevant when making a release from a 0.66.3
branch when the go version has already been bumped on master.
release.yml installs a fixed Go version for building a release, and it
must match the release.yml on master. A patch release from a branch off
an older tag is therefore built with master's Go version, not with the
one that branch uses. For example, once master moves to Go 1.27, a
v0.66.3 built from a branch off v0.66.2 would no longer run on macOS
12, although v0.66.2 does.
Read the version from the go line of the checked-out go.mod instead,
and add ".x" so that setup-go installs the latest patch release.
setup-go's go-version-file input can't do this; for "go 1.26.0" it
installs exactly 1.26.0. Read the version before pushing the tag, so
that a go.mod without a go line stops the release early.
This also removes release.yml from the files to edit when updating Go.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Releases run the release workflow of the stefanhaller/lazygit fork, but
build the code of jesseduffield/lazygit. If the fork's master is behind,
its copy of release.yml can differ from upstream's, and the release
runs with outdated steps. This may only show up after the new tag has
already been pushed.
Stop the release right after checking out the code if the running
release.yml differs from the one on jesseduffield/lazygit's master.
Compare with master rather than with the branch being released. A
patch release from a branch off an older tag carries an older
release.yml, and it should still be released with the current workflow.
This means that changes to release.yml can no longer be tried out in
the fork before they land upstream.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Dependabot PRs that update golang.org/x modules fail on CI. These
modules now require go 1.26, but CI runs 1.25. The golang.org/x modules
require the oldest Go release that is still supported, and since Go
1.27 came out, this is 1.26.
Stop at 1.26 rather than going to 1.27. The go version in go.mod is the
minimum for everyone who builds lazygit from source, and Go 1.27 is
only two months old. Also, Go 1.27 requires macOS 13, so release
binaries built with it would no longer run on macOS 12.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Updating Go means editing the go-version of six setup-go steps in
ci.yml. The workflow defines a GO_VERSION variable for this, but no
step has used it since it was added in a34bdf1a04.
Use it in all six steps. Give its value the ".x" suffix so that
setup-go keeps picking the latest patch release. This also keeps YAML
from reading a version like 1.30 as the number 1.3.
release.yml still needs its own update, because env variables don't
carry over to other workflows.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Two places pass plain text as the format string of TextStyle.Sprintf
without further arguments: the prefix of a disabled menu item's
tooltip, and the key binding entries of the options bar. If the text
contains a "%", for example in a translation or in a key label, it is
mangled into something like "%!(NOVERB)".
go vet doesn't report these calls yet. It will once go.mod says go
1.26, because vet then also finds printf wrappers through interface
methods. TextStyle.Sprintf forwards to the Sprintf method of the
Sprinter interface.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
When opening the `<ctrl+g>` files menu exactly at the moment where a
background fetch finishes, it could sometimes only show some of its
entries. The same could happen when pressing `>` to jump to the end of a
long diff at that moment.
Some actions read the content of the main view to the end before they
act on it: the jump-to-file menu, going to the bottom, searching, and
jumping to a file from the diffstat. If a re-render replaces the task
while it reads, these actions are told that the content has been read
although only a part of it has, so the menu lists only the files in
that part. A background fetch re-renders the main view once a minute,
so now and then the menu is incomplete. The same happens if a read is
asked for after a render has been asked for but before its task has
started.
These actions act on the content of the task asked for last, so leave
the reads waiting for content to that task. Hold them from the moment
the task is asked for, hand over the ones a replaced task hasn't
answered, including the one it was reading for, and answer them once
the task asked for last has given the view all of its content. The
replacing task still reads its own first lines first, so that the reads
it takes over don't delay its first paint.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Some actions read the content of the main view to the end before they
act on it. For example, the jump-to-file menu lists the files of the
diff. If the task reading the content is replaced by a re-render while
it reads, these actions act on the part that has been read so far, so
the menu shows only some of the files. A background fetch re-renders
the main view, so this happens now and then.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Discarding a nested repository deletes its directory like that of any
untracked file. If the repository keeps its git dir in its directory,
this deletes all of its history, and nothing said so. The directory of
a removed submodule keeps its git dir elsewhere, but it may have
changes that aren't committed.
Check for both before discarding. If anything would be lost, list it
and ask for confirmation.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
If nothing is staged, committing offers to stage all files first, or
stages them without asking if gui.skipNoStagedFilesWarning is set. Like
staging all files in the files panel, this adds a nested repository as
an embedded repository.
Show why the nested repository can't be staged instead, as staging all
files in the files panel does.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
If you staged the directory of a removed submodule, a nested repository
or a worktree inside the repo, git added it as an embedded repository: a
gitlink without an entry in .gitmodules. For a removed submodule, this
brings it back in a broken state. git warns about it, but lazygit didn't
show the warning. Staging all files did the same to every such
directory.
Disable staging a selection that contains one of these, and disable
staging all files if that would stage one. The disabled reason tells you
how to get rid of it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Selecting one of these in the files panel showed the error "Could not
access 'modules/sub/null'". The main view showed the entry's diff
against /dev/null with --no-index, as for an untracked file. When git
compares a file with a directory that way, it looks for a file of the
same name inside the directory.
Show what the directory is and what to do about it instead. Below that,
show the status of the repository that it is, or the files in it if it
is a plain directory. The status tells you whether discarding the
directory would lose anything.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
If a linked worktree lives inside the repo's working tree, it shows up
in the files panel. Discarding it there deleted its directory like that
of any untracked file. git still had the worktree on record, so the
worktrees panel listed it as missing, and its branch couldn't be checked
out anywhere else until the worktree was pruned.
Show the same menu for removing the worktree as the worktrees panel
does. Like a submodule, a worktree can't be discarded together with
other entries, because it has a menu of its own.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The files panel shows such a directory like an untracked file. Nothing
tells you that it is a directory, or that a submodule left it behind
when a commit that you checked out removed the submodule. This is the
case for the directory of a removed submodule, a nested repository, a
linked worktree inside the repo, and any untracked directory if
status.showUntrackedFiles is "normal".
Tell these apart when loading the files, by looking at the directory's
.git. Label removed submodules, nested repositories and worktrees, as we
already do for submodules, and put a slash after the name of a plain
directory, as git status does. With file icons on, a removed submodule
gets the submodule icon, and a nested repository or a plain directory
gets the directory icon.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
git status doesn't descend into a nested repository, such as the
directory that a removed submodule leaves behind. It reports the
directory as a whole, with a trailing slash. The file tree splits paths
at slashes, so it showed a directory with a file without a name in it.
Discarding the directory removed it, but then the cleanup of emptied
directories took the parent of "modules/sub/" to be "modules/sub"
itself, and failed to read it.
Take the slash off when loading the files. This also covers any
untracked directory if status.showUntrackedFiles is "normal", and linked
worktrees inside the repo. Their slash was taken off when they were
marked as worktrees; this is no longer needed.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
If a commit that you check out or pull removes a submodule, git leaves
the submodule's directory behind, and git status reports it as an
untracked directory. The files panel shows that directory with a file
below it that has no name. Discarding the directory shows an error,
even though the directory is gone afterwards.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
If the current worktree (or repo) that lazygit has open gets deleted
externally, lazygit used to crash with a panic. Exit gracefully in that
case, showing an error that the directory git deleted.
Also fix a crash for the more exotic case where a linked worktree's
directory is deleted and another worktree is created in the same
location. Users shouldn't do this, but it's still nicer to handle this
more gracefully.
Fixes#5266.
If the repo or linked worktree that lazygit has open is deleted while
lazygit is running, every git command fails. lazygit no longer panics
since the previous commit, but it shows empty lists, and there's
nothing useful left to do in it.
Check at the start of every refresh whether the worktree and its git
dir still exist. If one of them is gone, quit and print its path in
the terminal. The background files refresh does this check too, so
lazygit quits within ten seconds even if nobody is using it. To quit
from a refresh, return an error that wraps gocui.ErrQuit; this keeps
it out of the error popup.
Switching to another worktree or to a recent repo would be an
alternative, but it would be more surprising than quitting. Also,
there isn't always a main worktree to switch to.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The next commit makes performRefresh return early right after the
capture, and it must not leave the input blocked when it does.
This doesn't let any keypress slip through before the block begins.
Only refreshes on the UI thread block input, and there the capture
runs synchronously.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
If the repo that lazygit has open is deleted while lazygit is running,
the next full refresh panics. The same happens for a linked worktree
that is deleted. In both cases `git for-each-ref` fails because its
working directory is gone, and BranchLoader panics when that happens.
Return the error instead. The branches refresh logs it, like it does
with the other errors it gets from loading the branches.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
