Running integration tests from a tarball was never possible, but running
unit tests (`go test ./... -short`) was; this broke with v0.64.1
(specifically, with 34da956f5d). Make that possible again, and for all
tests now, including integration tests.
Running the tests in an exported source tarball fails with "must run in
lazy project folder or child folder". GetLazyRootDirectory searches the
working directory and its parents for a .git directory, and a tarball
doesn't have one. This has always affected the integration tests; since
34da956f5d a unit test calls the function too, so now even
`go test ./... -short` fails.
Search for the go.mod file that declares lazygit's module instead. It
ships in tarballs, and there is exactly one of it per source tree.
Put the function in our own pkg/utils rather than change lazycore's; the
criterion is specific to lazygit, and I don't feel like making a change
to lazycore.
Return an error rather than call log.Fatal, and report it from the two
callers that run under `go test`. In a test binary, log.Fatal exits
without attributing the failure to any test. That is the failure mode
34da956f5d set out to remove. The remaining callers are development
tools that have nothing useful to do without the root directory; they
keep exiting, now through MustFindLazygitRootDirectory.
Also stop the search at the root of the file system rather than at "/".
On Windows the old loop walks up to "C:\" and then spins there forever.
The whole-graph toggle hardcoded `--all`, which means every ref in the
repo. That is more than most people want: agent harnesses write large
numbers of refs under refs/agents, and stashes are refs too, so both
flood the commits view and bury the commits the user actually cares
about. There was no way to narrow the set short of turning the toggle
off entirely.
Add `git.log.allRefsArgs`, the args spliced into `git log` in place of
`--all`. It defaults to `["--all"]`, so existing behaviour is unchanged,
and can be set to something narrower such as `["--branches",
"--remotes"]`, or to `--all` plus `--exclude` globs.
Args rather than a whole command, as `git.allBranchesLogCmds` takes:
that pane dumps raw output into the main view, whereas the commits view
parses `git log` output field by field, so the pretty format and the
other flags have to stay under lazygit's control.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bumps [github.com/sirupsen/logrus](https://github.com/sirupsen/logrus)
from 1.9.4 to 1.10.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/sirupsen/logrus/releases">github.com/sirupsen/logrus's
releases</a>.</em></p>
<blockquote>
<h2>v1.10.2</h2>
<h1>Logrus v1.10.2</h1>
<p>This is a small maintenance release that updates
<code>github.com/stretchr/testify</code> to v1.12.1, removing the legacy
<code>gopkg.in/yaml.v3</code> dependency from Logrus' dependency graph.
There are no functional changes in this release.</p>
<p>Dependency Changes</p>
<ul>
<li>update github.com/stretchr/testify to v1.12.1</li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/sirupsen/logrus/compare/v1.10.1...v1.10.2">https://github.com/sirupsen/logrus/compare/v1.10.1...v1.10.2</a></p>
<h2>v1.10.1</h2>
<h1>Logrus v1.10.1</h1>
<p>This patch release fixes two issues in field formatting and
handling:</p>
<ul>
<li>Fix a regression introduced in v1.10.0 where
<code>TextFormatter</code> could panic
when formatting nil or panicking <code>error</code> and
<code>fmt.Stringer</code> values.</li>
<li>Allow function-backed values implementing <code>error</code> to be
used with
<code>WithError</code>, <code>WithField</code>, and
<code>WithFields</code>.</li>
</ul>
<p>Dependency Changes</p>
<ul>
<li>update github.com/stretchr/testify to v1.12.0</li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/sirupsen/logrus/compare/v1.10.0...v1.10.1">https://github.com/sirupsen/logrus/compare/v1.10.0...v1.10.1</a></p>
<h2>v1.10.0</h2>
<h1>Logrus v1.10.0</h1>
<p>This release focuses on substantial performance improvements,
concurrency correctness, and better interoperability with modern Go
logging APIs.</p>
<h2>🚀 Performance</h2>
<p>Major improvements across <code>TextFormatter</code>, entry handling,
and common logger paths:</p>
<ul>
<li>~17% lower geomean runtime across the benchmark suite</li>
<li>~27% higher geomean formatter throughput</li>
<li>Common enabled logging paths are ~30–44% faster</li>
<li><code>WithError</code> is ~40% faster</li>
<li>Chained fields are ~46% faster</li>
<li><code>TextFormatter</code> paths are up to ~40% faster</li>
<li>Allocation counts are reduced by ~25–74% across measured
<code>TextFormatter</code> cases, with the largest reductions in colored
output</li>
</ul>
<p>The improvements also show up in complete logger paths:</p>
<ul>
<li>Logger + <code>TextFormatter</code> is ~31% faster, with ~24% fewer
allocations</li>
<li>Logger + <code>JSONFormatter</code> is ~21% faster, with ~10% fewer
allocations</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/sirupsen/logrus/blob/master/CHANGELOG.md">github.com/sirupsen/logrus's
changelog</a>.</em></p>
<blockquote>
<h2>1.10.2</h2>
<p>Changed:</p>
<ul>
<li>Update <code>github.com/stretchr/testify</code> to v1.12.1, removing
the legacy
<code>gopkg.in/yaml.v3</code> dependency.</li>
</ul>
<h2>1.10.1</h2>
<p>Fixes:</p>
<ul>
<li>Fix a regression introduced in v1.10.0 where
<code>TextFormatter</code> could panic
when formatting nil or panicking <code>error</code> and
<code>fmt.Stringer</code> values.</li>
<li>Allow function-backed implementations of <code>error</code> as field
values.</li>
</ul>
<h2>1.10.0</h2>
<p>Fixes:</p>
<ul>
<li>Fix reentrant logging deadlocks in formatter paths.</li>
<li>Fix race conditions in formatter and entry handling.</li>
<li>Fix generic <code>Log</code>, <code>Logf</code>, <code>Logln</code>,
and <code>LogFn</code> methods unexpectedly
panicking when called with <code>PanicLevel</code>. Use the
corresponding <code>Panic</code>
methods when panic behavior is desired.</li>
<li>Improve concurrency safety around formatter and hook access.</li>
</ul>
<p>Features:</p>
<ul>
<li>Add <code>slog</code> hook for forwarding Logrus entries to
<code>log/slog</code>.</li>
<li>Add <code>slog.Handler</code> for forwarding <code>log/slog</code>
records to a Logrus logger,
including levels, fields, groups, context, time, and optional caller
reporting. The hook and handler can also be combined to help migrate
between Logrus and <code>log/slog</code>.</li>
<li>Add minimal, composable logging interfaces for each log level. This
enables
consumers to depend on narrower interfaces, making it easier to
substitute
or adapt logging implementations.</li>
<li>Allow <code>Entry.Caller</code> to be set explicitly and preserve it
across derived
entries, enabling custom caller detection without Logrus overwriting
caller information when <code>ReportCaller</code> is enabled.</li>
</ul>
<p>Changed:</p>
<ul>
<li>Raise minimum supported Go version to 1.23.</li>
<li>TextFormatter now renders <code>[]byte</code> values as raw/quoted
strings instead of slice-of-ints.</li>
<li>TextFormatter now uses distinct dimmed colors for debug and trace
output.</li>
<li>TextFormatter now automatically enables colors on Windows terminals
with ANSI support,
matching the behavior on other platforms.</li>
<li><code>Entry.HasCaller</code> is now deprecated in favor of checking
<code>Entry.Caller</code> directly.</li>
<li>Deprecated <code>MutexWrap</code>, which was unintentionally exposed
as public API.
It remains available as an alias for compatibility but should not be
used</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="6d6a132bc0"><code>6d6a132</code></a>
Merge pull request <a
href="https://redirect.github.com/sirupsen/logrus/issues/1586">#1586</a>
from thaJeztah/prepare_v1.10.2</li>
<li><a
href="4f9465318c"><code>4f94653</code></a>
update changelog for v1.10.2</li>
<li><a
href="87434bb3a7"><code>87434bb</code></a>
Merge pull request <a
href="https://redirect.github.com/sirupsen/logrus/issues/1585">#1585</a>
from thaJeztah/bump_testify</li>
<li><a
href="e7d2120300"><code>e7d2120</code></a>
chore(deps): bump github.com/stretchr/testify v1.12.1</li>
<li><a
href="8b673a9eb3"><code>8b673a9</code></a>
Merge pull request <a
href="https://redirect.github.com/sirupsen/logrus/issues/1583">#1583</a>
from thaJeztah/release_1.10.1</li>
<li><a
href="0b920add8d"><code>0b920ad</code></a>
Merge pull request <a
href="https://redirect.github.com/sirupsen/logrus/issues/1584">#1584</a>
from thaJeztah/more_coverage</li>
<li><a
href="5e20694a7a"><code>5e20694</code></a>
TextFormatter: cover nil pointer method receivers</li>
<li><a
href="83127326e4"><code>8312732</code></a>
update changelog for v1.10.1</li>
<li><a
href="e987a4036b"><code>e987a40</code></a>
Merge pull request <a
href="https://redirect.github.com/sirupsen/logrus/issues/1582">#1582</a>
from thaJeztah/panic_handler</li>
<li><a
href="17d574b11e"><code>17d574b</code></a>
TextFormatter: recover panics from Error and String methods</li>
<li>Additional commits viewable in <a
href="https://github.com/sirupsen/logrus/compare/v1.9.4...v1.10.2">compare
view</a></li>
</ul>
</details>
<br />
When searching the focused main view using `/`, any updates to its
content were ignored because back when we introduced the focused main
view feature we couldn't make it work; search mode couldn't cope well
with the view content changing under it.
In this PR we make that work, and remove the limitation. Along the way
we fix a bunch of other related problems; some are only theoretical race
conditions that have been found by reading the code, but never observed
in reality; some are real problems that are too edge-casey to describe
in detail. See the individual commit messages for details.
A refresh left the focused main view alone while a search was on, so the
diff on screen stayed as it was however much the working tree had moved
on underneath it. The search could not cope with the content changing
under it, and leaving the content alone was the way around that.
It can cope now. The positions are worked out again from whatever the
view holds, and the status with them, so render it like any other.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rendering a view's content again while a search is on leaves the "x of y"
describing the content that has just been replaced. The status is worked
out when the search is typed and again when a key steps through the
matches, and a render is neither. Change the diff context size while
searching the focused main view, and the count stays as it was, however
many matches the wider context brought in or took away.
Run the search again over the new content once the render has finished
putting it there.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Opening the search prompt reads the whole of the view's content, so that
the search counts every match in it. Rendering the content again reads
only as much as the scrollbar needs, so the matches below that point are
lost. The "x of y" drops to what the shortened content holds, and grows
again as the user scrolls far enough to load more.
Read to the end while a search is on, the way opening the prompt does.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A view's search positions were worked out again from every write, and
each of those walks the whole view. Content arrives a line at a time, so
rendering into a searched view costs a walk per line. Streaming 2000
lines takes 565ms, where the same render into an unsearched view takes
about 10ms.
Mark the positions stale on a write instead, and work them out where they
are read: when the view is drawn, when a key steps through the matches,
when the status is asked for. That is at most once a frame, and the same
2000 lines now take 8ms.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Search a view, step to the last match, then have the view re-rendered
with fewer matches in it, and the status reads "3 of 1". The positions
are worked out again whenever the content changes, but the index into
them stays where it was. Stepping on from there indexes the positions
out of range and panics.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
ReadToEnd reads the rest of a view's content on the render task's own
goroutine, and calls back once it has. Nothing held a task for that, so
lazygit counted as idle from the moment the caller returned until the
callback ran. The search prompt in the focused main view opens from such
a callback, so an integration test takes the idle report as its cue to
carry on, and presses its next key while the prompt is not open yet.
Hold the task in ReadToEnd rather than in the caller, so that every
caller is covered (see docs/dev/Busy.md).
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A caller of ReadLines or ReadToEnd is told that the content it asked for
has been read by the request's Then being called. A task that reaches the
end of its input answers the requests still queued behind the one it was
serving, but a task that is stopped drops them, and their callers wait
for a callback that never comes. Pressing "/" in the focused main view
opens the search prompt from such a callback, so if a re-render replaces
the task at that moment the prompt never opens.
Answering them as the read loop ends would leave a request handed over
after that point unanswered, and there is a window for one. A caller
reads the channel to send on, and can reach the send itself only once the
loop has gone. So hand requests over through a queue instead. Asking
whether a task is there and giving it the request are one step, as are
taking the task away and handing back what it never answered; a request
made in between goes back to the caller to answer.
The queue is unbounded rather than a fixed-size channel, for the reasons
gocui's userEventQueue is. Requests are handed over from the UI thread,
where a blocking send would deadlock against the task waiting to be let
go, and a fixed channel that fills up leaves only blocking, dropping,
reordering or panicking to choose between.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ask a view buffer manager to read to the end of its content twice over,
then stop the task before it has served either request, as a re-render
replacing it does. Only the request it had already picked up is answered;
the one still queued behind it is dropped, and its caller waits for a
callback that never comes.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two places nudged the flags because nothing else would: switching repos,
where the view focused in the repo being left is not the one focused in the
repo being entered, and tabbing from the suggestions list back to the
prompt, which replaces the top of the stack rather than popping it, so the
suggestions context never hears that it lost the focus. Both are just a
context leaving the stack now.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A view drew a selection because something told it to, from four places on
three different schedules: a context being focused, a context losing focus,
a context being activated over another one, and a list being re-rendered.
Whether the flags ended up describing the state of the app depended on
which of those had run last, and the last one to run was often none of
them: a refresh only re-focuses the view that has the focus, so a list
whose contents changed underneath an unfocused panel kept whichever
highlight it happened to have.
Derive both flags instead, in one place, from the two things they mean: a
view shows a selection while its context is on the stack and has something
to select, and the context the user is in shows an active one where the
ones behind it show inactive ones. Nothing else needs to say anything about
highlighting, so nothing else can leave a view saying something untrue
about where the focus is.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Toggling whitespace needs the panel beneath to render its diff again, which
is what HandleRenderToMain is for; HandleFocus does that and also everything
else that belongs to a panel gaining the focus, which this panel already has
or, when the focus is in the main view, does not want. Re-selecting its
current item is harmless, but re-deriving its highlight as a focused panel's
is not: the selection turns bright while the user is somewhere else.
Changing the context size and switching diff renderers already ask for a
re-render this way.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Toggling whitespace re-focuses the side panel to re-render the diff, which
also re-derives that panel's highlight — as though the panel had the focus,
which it doesn't.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A refresh only re-derives the highlight of the view that has the focus, so
a list whose contents change while the user is somewhere else keeps the
selection it had: none for a list that just got its first item, and one
over nothing for a list that just lost its last.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Whether a view draws a selection is about to be derived in one place from
the context stack, which needs to ask any context — list or not — whether
there is something for a selection to sit on. Name the existing flag after
that question, and let a list context answer it from its length.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nothing said that a context leaving the stack takes its selection with it,
which the work coming up is about to make the rule for every view. Two
places already depend on it and are held together by hand: switching repos,
where the view focused in the repo being left is not the one focused in the
repo being entered, and tabbing from the suggestions list back to the
prompt, which replaces the top of the stack rather than popping it.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The selected line of a view says nothing about whether a selection is drawn
over it, or which of the two ways it is drawn in, and those are what the
tests coming up are about.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
If a custom command's "context" field contains a context name that
doesn't exist, lazygit panics when building the keybindings. This could
happen either because of a typo, or because a context is removed or
renamed in a later version. Prevent the panic by validating those names
at config load time, and rejecting the config as invalid there, like we
do for other config errors.
If a custom command's "context" field contains a context name that
doesn't exist, lazygit panics when building the keybindings. This could
happen either because of a typo, or because a context is removed or
renamed in a later version. Prevent the panic by validating those names
at config load time, and rejecting the config as invalid there, like we
do for other config errors.
The gui package owns the list, but can't be imported from here, so it is
mirrored and a test over there ensures the copies stay in sync.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
All menus in lazygit can be filtered by pressing the `/` key; for most
menus which only show a handful of choices this is not really needed,
but with the two cases where it's useful, it was unnecessarily
inconvenient: you first have to press `/` to open the filter prompt, and
then press enter to confirm the filter before you could press enter
again to trigger the chosen item. It's much easier to simply type to
filter, and still use the arrow keys to select one of the filtered
items, or press enter to trigger it while the filter prompt is showing.
The consequence of this is that while the keybindings menu is open you
can no longer use the displayed key bindings to trigger the commands; I
think that's fine, that menu is more for looking up those keybindings
rather than for using them from within the menu.
Also: since `j`/`k` are bound to move the list selection by default, it
is not possible to filter for something that begins with `j`/`k`. I
didn't want to change this because I'm concerned that die-hard vim users
would perceive it as a regression if they can no longer type `j` to
select the next menu item. The workaround is to type some other letter
and backspace; this keeps the filter prompt open, so you can now type
`j` or `k`.
There is no `reservedKeys` any more; the list of keys that menu items must
not shadow is `essentialKeys` in the function that creates the menu.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Picking a repository out of that list is the other place where the menu is
a list to search rather than a set of commands, and its items have no keys
that typing could clash with.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The only menu that ever asked for it was the keybindings menu, which now
filters as you type and doesn't use the prompt at all. That leaves every
filterable context with the same prompt, so the whole hook can go, and
with it the two implementations that only existed to satisfy it.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Looking up a keybinding is a search, so the menu that lists them is the
one that most wants this. Its items do have keys, but only as a reminder
of what they do outside the menu, so nothing is lost by not binding them.
The prompt in front of the input field says what '@' does. It only ever
showed up while the user was typing in the search prompt, so it could
afford to be wordy; on a row that is on screen for as long as the menu
is, it can't.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Its footer, the hint in the menu's subtitle, where the row sits in
relation to the menu and the tooltip, and whether the text cursor is
showing are all things the tests for it need to look at.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The keys for paging through a menu are ',' and '.' by default, and there
is no non-printable alternative for them, so a menu that filters as you
type would lose paging altogether as soon as the user typed anything. The
same goes for confirming and cancelling if those keys are configured as
printable ones.
So bind the physical keys for all of it, on top of whatever is configured,
and only where they aren't the configured keys anyway.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The filter input is where the keyboard points for as long as such a menu
is open, so that the first printable key can go straight into it. The menu
still gets every key the input doesn't take, because the input view is
embedded in the menu view, and the two are drawn as one focused panel.
Which keys the input takes changes once there is a filter: until then
printable keys still drive the menu, so that the configured navigation
keys work as usual, and afterwards they are all filter text. A menu item's
own keys are never bound in such a menu, because typing one has to reach
the filter rather than execute the item.
Escape gives up the filter and leaves the menu open; the next one closes
it. The filter prompt behind '/' is gone from these menus: the row already
does that job, and a second filter would only be confusing.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The row is reserved for as long as such a menu is open, even while it is
still hidden, so that it can appear without moving the menu. That costs
two rows of the popup, which is why the screen has to be a little taller
before a menu is worth showing at all.
The prompt in front of the input field is dropped when the row gets too
narrow to type in, and the keybindings menu says what '@' does when it
still fits.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
