Commit graph

3 commits

Author SHA1 Message Date
Stefan Haller 35d3659cce Use more widely-supported Unicode symbols for the commit graph
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>
2026-05-04 13:06:29 +02:00
Stefan Haller 82e1caa166 Remove conditional code related to git earlier than 2.22 2025-04-09 10:40:52 +02:00
Stefan Haller 078445db63 Allow deleting a merge commit
For non-merge commits we change "pick" to "drop" when we delete them. We do this
so that we can use the same code for dropping a commit no matter whether we are
in an interactive rebase or not. (If we aren't, we could just as well delete the
pick line from the todo list instead of setting it to "drop", but if we are, it
is better to keep the line around so that the user can change it back to "pick"
if they change their mind.)

However, merge commits can't be changed to "drop", so we have to delete them
from the todo file. We add a new daemon instruction that does this.

We still don't allow deleting a merge commit from within an interactive rebase.
The reason is that we don't show the "label" and "reset" todos in lazygit, so
deleting a merge commit would leave the commits from the branch that is being
merged in the list as "pick" commits, with no indication that they are going to
be dropped because they are on a different branch, and the merge commit that
would have brought them in is gone. This could be very confusing.
2024-12-23 12:12:45 +01:00