The commit graph used '⏣' (U+23E3 BENZENE RING WITH CIRCLE) for merge
commits and '◯' (U+25EF LARGE CIRCLE) for regular commits. Both have
very poor coverage in popular monospace fonts:
- '⏣' lives in the Misc Technical block and is essentially absent from
every common monospace font (Source Code Pro, JetBrains Mono, Fira
Code, Cascadia Code, Hack, Iosevka, Menlo, Consolas, Monaco, IBM
Plex Mono, Ubuntu Mono, Noto Sans Mono, Inconsolata). It is always
drawn from a system fallback font.
- '◯' is the late-addition LARGE CIRCLE codepoint. It is present in
some fonts (Cascadia, Fira Code, Hack, Iosevka, Menlo, Noto Sans
Mono) but missing from many others, including Source Code Pro and
most Nerd Font derivatives based on it.
This is why the graph renders inconsistently across platforms even
when the same monospace font is configured: each OS picks a different
fallback font (Apple Symbols on macOS, Segoe UI Symbol on Windows,
Noto/DejaVu/Symbola on Linux), and the substituted glyphs differ in
shape, weight, and advance width. '◯' is also East Asian Ambiguous
width, so some terminals render it wider than one cell, exaggerating
the misalignment.
Replace the symbols with codepoints from the foundational 1991
Geometric Shapes block, which has far broader font coverage:
- Merge: '◎' U+25CE BULLSEYE -- concentric circles, the visually
closest cousin to the previous benzene-ring glyph.
- Commit: '○' U+25CB WHITE CIRCLE -- the same hollow-circle silhouette
as before, just a more universally available codepoint.
The new symbols are present in the font directly in significantly
more cases; and when fallback is still required, they are universally
well-drawn (unlike '⏣', which many fallback fonts also lack).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Windows cannot remove files while handles are still open. In
TestOSCommandFileType we created files and immediately called RemoveAll without
closing handles, which left untracked artifacts (e.g. "testFile" and "file with
spaces") in the working tree. Close the handles and assert RemoveAll succeeds so
cleanup failures are visible.
The call was meant to guarantee a UTC time zone to make the tests deterministic,
but as the previous commit explained, this only worked on Mac and Linux, not on
Windows. Since we now have a better fix, this workaround is no longer needed.
The "custom time format" test case of TestGetCommitListDisplayStrings failed on
Windows. Root cause: UnixToDateSmart used time.Unix(timestamp, 0), which formats
in process-local time. In tests we pass an explicit 'now' (often UTC), but the
timestamp was rendered in Local, causing one-hour drift on non-UTC machines.
The test tried to work around this by doing os.Setenv("TZ", "UTC"); however,
this only worked on Mac and Linux. On Windows, it has no effect because Windows
uses registry-based timezone configuration, not TZ environment variables.
Change: convert the timestamp into now.Location() before both the same-day
comparison and formatting.
Why this is safe: callers already define the presentation timezone via the 'now'
argument (typically time.Now() in app code, controlled time in tests). This
aligns timestamp rendering with that caller intent and removes dependence on
global TZ state or OS-specific environment variable behavior.
Added regression tests for UTC and UTC+1 to ensure deterministic behavior across
all platforms.
In the event that LC_ALL was set, for example, the tests would fail as
it takes precedence over LANG.
Tiny change that prevents language tests from failing if LC_ALL is set
(I also added LC_MESSAGES but I am not sure if that's also needed, from
what I read it also takes precedence) so I did not open an issue prior,
hopefully that's ok!
These have alternate keys (`<ctrl+h>` for backspace, and `<ctrl+f>` for
move-cursor-right). Both of these broke with commit 22169e22ffc46c5; the
first because it was accidentally omitted, the second because of a
stupid copy/paste mistake.
These have alternate keys (<ctrl+h> for backspace, and <ctrl+f> for
move-cursor-right). Both of these broke with commit 22169e22ffc46c5; the first
because it was accidentally omitted, the second because of a stupid copy/paste
mistake.
In #5563 we started to support an alternative syntax for keybindings:
instead of `<c-a>` you could say `<ctrl+a>`, which is easier to read
especially when there are multiple modifiers (`<ctrl+shift+x>` instead
of `<c-s-x>`). In this PR we make this new syntax the default.
Make the edit keybindings for "move-by-word" and "backspace-word"
platform-dependent so that they are with ctrl on Windows and Linux, but
alt on Mac. These are the common conventions on these platforms. Also,
make them configurable so that user who can't get used to the change can
map it back to what they were.
Add a "forward-delete-word" keybinding, bound to alt-delete on Mac, and
ctrl-delete on Windows and Linux.
Revamp lazygit's keybinding mechanism to support richer keybindings for
those terminals that support the newer keyboard protocols. This makes it
possible to use keybindings such as `ctrl-alt-shift-x`.
Change the default keybindings for moving commits up and down from
`ctrl-k`/`ctrl-j` to `alt-up`/`alt-down`; this is mostly for personal
preference, I find them easier to remember, and they are nicely similar
to moving a line of code up and down in many code editors. Also, change
the default binding for submitting a commit from the commit description
editor from `alt-enter` to `command-enter` on Mac, or `ctrl-enter` on
Linux and Windows; these are the same bindings that are used in many
multi-line edit field situations, e.g. in GitHub comments.
See docs/keybindings/Custom_Keybindings.md for caveats about terminal
compatibility.
The previous version only enumerated the supported (non-rune) bindings.
Replace it with a description of the syntax: how to spell single-rune
keys, special keys, and modified keys; how to combine modifiers; the
keyword forms for `<space>`, `<minus>`, `<plus>`; and which combinations
are rejected because terminals can't deliver them.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This changes not only how we store modifiers (inside of Key instead of passing
it separately), but also how we parse keybinding strings: it supports all
combinations of modifiers now (if the terminal supports it, that is).
An uppercase letter is not valid with ctrl, and only works because we lowercase
the string before parsing it. This will change later in this branch when we
start supporting bindings like <c-s-r>.
Refactor code to introduce a Key type in gocui that bundles the keyName
and a rune, so that we don't have to pass these around separately
everywhere.
This, and updating tcell to v3 lays the ground for supporting more
keybindings in terminals that support the CSIu keyboard protocol.
This bundles the keyName and a rune, so that we don't have to pass these around
separately everywhere. This should make it easier to swap out the rune for a
string when we upgrade to tcell v3.
Over the past few months or even years, [Jesse's gocui
fork](https://github.com/jesseduffield/gocui) has become more and more
tied to lazygit; I have repeatedly made API-breaking changes to it
without caring much about what this means for other clients like
lazydocker or lazynpm (and Jesse was ok with that).
Given that situation, it no longer makes much sense to maintain it in a
standalone repo, so copy it into lazygit; this will greatly reduce the
friction of making changes to it. If/when the time comes to update those
other clients to also benefit from the improvements we make here, we can
always copy the files back to the gocui fork and resume it there.
I copied all files except dot files (.github and .gitignore), the _examples
folder, and go.mod/go.sum.
At some point we may want to copy the files back to the gocui repo when other
clients (e.g. lazydocker) want to use the newer versions of them.
### PR Description
Instead of manually figuring out how much ahead each branch is from it's
upstream branch, use [for-each-ref
ahead-behind](https://git-scm.com/docs/git-for-each-ref/2.41.0#Documentation/git-for-each-ref.txt-ahead-behindcommittish)
if supported by the git binary.
On my Windows machine, using the lazygit repo with all 61 branches
created locally, it goes from ~8.5s to ~200ms.
It was also able to find a base branch for `assets` which the previous
iteration did not.
Fixes#5532
Stefan Haller
stk
Antoine Gaudreau Simard
Antoine Gaudreau Simard
dependabot[bot]