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>
If a linked worktree's directory is deleted and another worktree is
moved to the same path, `git worktree list` reports both worktrees with
that path. lazygit then crashes at startup with a stack overflow, and
the terminal is left in a broken state.
To tell the paths in a group apart, getUniqueNamesFromPathsAux keeps
looking at one more parent directory, but identical paths never come
apart, so it recurses forever. A stack overflow is a fatal error rather
than a panic. No deferred function runs, so the terminal is not
restored either.
Name identical paths like a single path instead of recursing.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
It returns true if the path is missing. It started out as
IsWorktreePathMissing, and was renamed without inverting its result
when it moved into the loader in de57cfd6ff.
Invert the result instead of renaming it back, so that the call site
reads `IsPathMissing: !self.pathExists(path)`. If we can't check the
path, it still counts as existing, as it always did.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
We already have a mechanism in place that takes care of restoring the
terminal if a panic occurs, but it was not consistently used. Use it for
all goroutines, and add a test that guards against forgetting it when we
add new ones.
When starting a new goroutine, it is easy to forget utils.Safe, and
nothing tells us until a panic in it leaves somebody's terminal
broken.
The test parses our source files and reports go statements that don't
run utils.Safe. It also reports functions given to time.AfterFunc or
to a Go method, such as errgroup.Group.Go, that aren't wrapped with
utils.SafeFunc or utils.SafeFuncWithError. It only looks at the
syntax; this is good enough because the names involved are
distinctive.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
time.AfterFunc and errgroup.Group.Go run the function they are given
on a goroutine of their own, so a panic in it leaves the terminal in
raw mode, like a panic in any other goroutine that doesn't use
utils.Safe.
Add utils.SafeFunc and utils.SafeFuncWithError, which return a copy
of a function that runs through utils.Safe or utils.SafeWithError, and
use them for the functions given to time.AfterFunc and errgroup.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Most goroutines run their function through utils.Safe, which closes
the screen if the function panics. Without it, the panic is printed to
a terminal that is still in raw mode and on the alternate screen, and
the terminal needs a reset afterwards. Go has no process-wide hook for
panics, so every goroutine has to do this itself.
Use utils.Safe for the goroutines that don't use it yet.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A panic in the goroutine that polls the terminal for events leaves the
terminal in raw mode and on the alternate screen. The panic is then
hard to read, and the terminal needs a reset afterwards.
Guard this goroutine the same way as the worker goroutines. Guard the
goroutines that send a resize event too; they are unlikely to panic,
but this way all of gocui's goroutines are guarded, and a check for
unguarded goroutines doesn't need any exceptions.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Lazygit decided whether two clicks form a double click based on the
times it handled them. This can lead to false results: if the first
click takes the UI thread more then 500ms to handle, then the second
click is not detected as a double click even when it happened quickly
after the first. Conversely, if two clicks happen a second apart while
the main loop is busy, they are handled quickly once the main loop
unblocks, and got detected as a double-click.
I never actually ran into either of these problems in practice, and we
try hard to prevent lazygit from blocking the UI for longer than
necessary. I only noticed this because an integration test that performs
a double click occasionally fails when the CI runner is under heavy
load.
Fix this by recording the times at which the events were received, and
use those for double-click detection.
gocui decides whether two clicks form a double click by the time it
handles them. If handling the first click keeps the main loop busy for
more than 500ms, a quick second click doesn't count as a double click.
The other way round, two separate clicks that wait in the event queue
while the main loop is busy count as a double click.
Compare the times at which tcell read the clicks instead. For events
replayed by integration tests, this is the time the test created them.
This way, a DoubleClick in a test no longer depends on how fast lazygit
handles the first click.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
If the main loop is busy, clicks wait in the event queue and are then
handled right after each other. gocui decides whether two clicks form a
double click by the time it handles them, so two clicks read more than
500ms apart count as a double click.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Every caller passes 0, and nothing reads it. The next commit makes
replayed mouse events carry the time they were created; a second, unused
timestamp next to it would only confuse.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The test enter_and_double_click_focus_file_diff fails occasionally on
CI. After it double-clicks a file, the files panel still has the focus
instead of the main view.
The test double-clicks by calling Click twice. Click waits for lazygit
to become idle after the press and again after the release, and the
first wait includes the git diff that the click starts for the main
view. gocui only counts the second click as a double click if it handles
it within 500ms of the first one. On a busy CI runner, where many
integration tests run in parallel, the waits can take longer than that,
and the second click counts as a single click.
Add DoubleClick to the test driver. It replays both clicks without
waiting in between, as a terminal reports a double click, and waits for
lazygit to become idle only after the second one.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Parsing long diffs was very slow, especially for commits that add or
remove files with hundreds of thousands of lines. This caused very
noticeable lags for certain operations such as scrolling down in such a
diff using `>`, or bringing up the `<ctrl-g>` files menu.
Under a diff renderer that states which diff line each row shows, such
as delta, the queries about the lines of the main view read the rows by
those records alone. Still, they took the text of every row as well,
and for a diff of 300,000 lines this was most of the time each of them
took. Moving the selection by change block runs two of them for every
key press.
Take the records of the rows first, and their text only if no row
states a diff line.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Under a diff renderer that states which diff line each row shows, such
as delta, moving the selection by change block in a diff of 300,000
lines lags noticeably. One reason is that the queries about the lines
of the main view collect the records of every row from the row's
cells, going through every cell of every row. Under delta, a row has
about 130 cells.
Collect the records of a line once, when the write cursor moves on to
the next line, and take them from there. A line that is written to
again is read from its cells until it has been finished again.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Every query about the lines of the main view, such as moving the
selection to the next change block, finds out which line of which file
each row shows. For every row, this joined the path that the diff
states with the path of the worktree. In a diff of 300,000 lines, this
took more than half of the time of the query.
The lines of a diff come file by file, so remember the last path that
was made absolute and reuse it while the path stays the same. Do the
same in the other places that go through every line of a diff. A query
over that diff now takes about 27 milliseconds instead of 63.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Several actions on the selected lines of a diff look up those lines in
the diff of their file by their line numbers: staging, unstaging and
discarding them, editing the hunk they are in, and adding them to a
custom patch. Showing which lines of a diff are in the custom patch
does the same lookup the other way round. For this, the change lines of
the file's diff are indexed by their line numbers.
The index asked the patch for the number of each change line separately,
and each of these calls counts the lines of the hunk before the line. So
for a new file of 100,000 lines, building the index took 2 seconds.
Number all lines of the patch in one pass instead. Building the index
for that file now takes 4 milliseconds.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
With no diff renderer configured, opening the jump-to-file menu for the
diff of a commit that adds or deletes a file of 100,000 lines takes
more than 20 seconds, and so does picking a file from it. In such a
diff, moving the selection by change block takes as long for each key
press. All this time the UI is frozen.
To find out which line of which file each row of the main view shows,
lazygit parses the view's content as a diff. For every line of a file's
diff it asks the parsed patch for the line's number in the new and in
the old file, and each of these calls counts the lines of the hunk
before it. So parsing takes time quadratic in the length of a hunk, and
the diff of a new or deleted file is a single hunk. For a diff of
200,000 lines, one parse took about 10 seconds, and opening the menu
parses it twice. A diff renderer that states which line each row shows,
such as delta, doesn't go through this parse.
Number all lines of the patch in one pass instead. Parsing that diff
now takes about 40 milliseconds.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Fix a regression introduced in v0.65.0: if the main view is scrolled
more than about 5000 lines down a diff and another commit with a diff of
more than 5000 lines is selected, the main view kept showing the
previous diff. Switching between the two long commits then didn't update
the main view at all. Only selecting a shorter commit would get this
unstuck.
Along the way, fix another smaller bug and a performance problem; see
commit messages for details.
A render first reads enough lines to fill the view, plus the lines
above the view, so that a re-render of the diff the user is scrolled
into fills the view where it is. But a render of another diff, such as
the diff of another commit, is shown from the top. So if the view is
scrolled far down a long diff, the next diff only shows up once the
lines above the view have been read as well. For a diff of a few
hundred thousand lines this takes a noticeable while, especially with a
diff renderer such as delta.
ViewBufferManager decides whether a render keeps the view where it is
(see newContentPending). So let linesToReadFromCmdTask count the lines
from the top of the view and pass on how many lines are above it, and
let the task add those only if it keeps the view where it is.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
