If a diff renderer is configured, its command shows up in the command
log once after startup, although the user didn't do anything. This is
the probe that asks the renderer whether it emits OSC 1717 metadata. It
changes nothing, so like other read-only commands it shouldn't be
logged.
If a diff renderer is configured, its command shows up in the command
log once after startup, although the user didn't do anything. This is
the probe that asks the renderer whether it emits OSC 1717 metadata. It
changes nothing, so like other read-only commands it shouldn't be
logged.
This is an improvement for users who use a side-by-side diff renderer on
a very large screen; in this scenario it was hard to see which hunk on
the right side was selected.
If you enter a branch in the branches panel and press `e` on a line of a
commit's diff, or on a file in the commit files panel entered from
there, lazygit opens the file in the current worktree. If another
worktree has the branch checked out, this is the wrong copy of the file.
The current worktree may have it in a different state, or not have it at
all. Clicking a lazygit-edit:// hyperlink of a diff renderer in such a
diff has the same problem.
Fix this by opening the file from the worktree that has the branch
checked out instead, and carry the line number forward to the file as
that worktree has it. If no other worktree has the branch checked out,
the file is still opened from the current worktree.
Also, fix the same problem for the `o` command, and for the "Absolute
path" entry in the "Copy to clipboard" menu.
Finally, fix a long-standing annoyance when trying to open a file that
has since been deleted or renamed; in that case, most editors would
create it as a new, empty file, which is not useful. Show an error
message in that case instead.
Fixes#6102.
If you press `e` on a file of a commit, and a later commit deleted that
file, the editor is opened on a path that doesn't exist. Most editors
then create it as a new, empty file. This is confusing. The same
happens with `o`, and with any other file that the worktree it is
opened from doesn't have. An example is a file that is added in a branch
that isn't checked out anywhere, since it is opened from the current
worktree.
Show an error instead of opening the editor. For a range selection in
the commit files panel, show it only if none of the selected files
exist. Otherwise open the existing ones and leave out the others
silently; an error shown only after returning from the editor would
come too late to be useful.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If the commit files panel was entered from a branch that another
worktree has checked out, "Copy absolute path" in its copy menu gives
the file's path in the current worktree. Make it give the path in the
worktree that has the branch checked out. This is the file that `e` and
`o` open, and the one users most likely want the path of.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Do the same for `o` in the commit files panel as the previous commits
do for `e`. If the panel was entered from a branch that another worktree
has checked out, open the file from that worktree.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Pressing `o` on a file in the commit files panel has the same problem as
`e` had before the previous commit. If the commit is of a branch that
another worktree has checked out, the file is still opened from the
current worktree. The absolute path in the panel's copy menu points into
the current worktree too.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If you enter a branch in the branches panel and press `e` on a line of
a commit's diff, or on a file in the commit files panel entered from
there, lazygit opens the file in the current worktree. If another
worktree has the branch checked out, this is the wrong copy of the
file. The current worktree may have it in a different state, or not
have it at all. Clicking a lazygit-edit:// hyperlink of a diff renderer
in such a diff has the same problem.
Open the file from the worktree that has the branch checked out
instead, and carry the line number forward to the file as that worktree
has it.
If no other worktree has the branch checked out, the file is still
opened from the current worktree.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If you enter a branch in the branches panel, and that branch is checked
out in another worktree, pressing `e` on a line of a commit's diff opens
the file in the current worktree. The same happens for `e` on a file in
the commit files panel entered from there. The current worktree may not
have the file at all, as in this test, or have it in a different state
than the branch has it. The line number is carried forward to the
current worktree's version of the file too, and this gives line 0 here.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The next commit carries a line of a diff forward to the file as another
worktree has it, and needs to diff against that worktree's working copy
for this.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Three places open a file of a diff in the editor: `e` and alt-click in
the main view, the lazygit-edit:// hyperlinks of a diff renderer, and
`e` in the commit files panel. The first two also each carry a line of
the diff forward to the file's current line before opening it.
Give them one pair of methods to call. The next commit changes where
these files are opened from, and can then do so in one place.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If gui.wrapLinesInDiffView is false, long lines of a diff run off the
right edge of the main view, and there was no way to see the rest of
them. This made it hard to see what has changed in such a line. The old
staging and patch-building views scrolled sideways with `H` and `L`, but
the focused main view that replaced them had no binding for these keys.
Bind them in the focused main view, as in the side panels. Leaving the
view scrolls it back to the left edge, as it did for the staging view.
In addition, when jumping to the next search result, and it is past the
right edge, scroll sideways to show it. This happens both in the new
main view when `gui.wrapLinesInDiffView` is off, but also in side
panels, so it is an improvement over pre-0.66 versions there.
If a view doesn't wrap, a search match can be past its right edge, or
left of it once the view is scrolled sideways. Going to such a match
with /, n or N only scrolls the view vertically, so the match stays out
of sight. This matters most for a diff with gui.wrapLinesInDiffView set
to false, where a change is often at the end of a long line.
Scroll the view sideways if the match isn't on screen. Put the match a
third of the way across the view, so that some of the text before it
shows too. If the view can show the match without scrolling, go back to
the left edge instead. This applies to every view that doesn't wrap,
including the side panels.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If gui.wrapLinesInDiffView is false, long lines of a diff run off the
right edge of the main view, and there is no way to see the rest of
them. This makes it hard to see what has changed in such a line. The
old staging and patch-building views scrolled sideways with H and L, but
the focused main view that replaced them has no binding for these keys.
Bind them in the focused main view, as in the side panels. Leaving the
view scrolls it back to the left edge, as it did for the staging view.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Going to the next or previous file of a diff, or picking one from the
jump-to-file menu or the diffstat, brings that file to the top of the
view. The user goes there to read the file from its start, so scroll the
view back to the left edge as well. Jumps between the hunks of a diff
keep the horizontal scroll position, as moving the selection does.
Nothing scrolls the main view horizontally yet, so this changes nothing
on its own. It prepares for scrolling the focused main view sideways
with H and L.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The main view keeps its horizontal scroll position when a diff is
rendered again. If the new rendering is narrower, for example because
the only long line in it was just staged, the view can end up scrolled
past the end of every line and look empty. If one line still reaches
into the view, the view shows only a sliver of it, although the whole
diff would fit without scrolling.
Once a render has been read to the end, scroll the view back as far as
it takes to put the end of the widest line at the right edge. A long
diff that is read only in part is checked once the rest of it has been
read.
Nothing scrolls the main view horizontally yet, so this changes nothing
on its own. It prepares for scrolling the focused main view sideways
with H and L.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Two places that position the main view after a re-render of the same
diff call SetOrigin(0, y), although they only mean to move the view
vertically. One is the restore after a change of the context size, of
whitespace handling or of the diff renderer. The other is the clamp for
content that ends above the scroll position, for example after staging a
large part of the diff. Use SetOriginY in both, so that they keep the
horizontal scroll position.
Nothing scrolls the main view horizontally yet, so this changes nothing
on its own. It prepares for scrolling the focused main view sideways
with H and L.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If a view that shows the inclusion gutter is scrolled horizontally, its
content is drawn over the gutter. The marker of a marked line is
overwritten, and the content starts the gutter's width too far to the
left. The draw loop skips the cells scrolled past the left edge only
until x reaches 0, but the content area starts at the gutter's width.
Nothing scrolls such a view horizontally yet. A later commit lets the
focused main view scroll sideways, and the gutter shows there while
building a custom patch.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Search matches beside the inclusion gutter were highlighted in the wrong
place, and hovering over or clicking a hyperlink there acted on the
wrong cell. The draw loop starts the content after the gutter, but the
code that maps a view column back to a column of the content only added
the horizontal origin and ignores the gutter.
Add a helper that does both, and use it for search highlights, hover and
clicks.
Nothing in lazygit calls View.Line or View.Word; they came with the
original gocui code and have never been used. They are also the only
callers of realPosition. That function ignores the inclusion gutter when
it maps a view position to the buffer. On top of that, Word uses the
returned column as an index into the line's cells, and this goes wrong
for wide characters.
Remove them, together with realPosition and the indexFunc helper. This
leaves contentX as the only code that maps a column of the view to a
column of the content.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Search matches beside the inclusion gutter are highlighted in the wrong
place, and hovering over or clicking a hyperlink there acts on the wrong
cell. The draw loop starts the content after the gutter, but the code
that maps a view column back to a column of the content only adds the
horizontal origin and ignores the gutter.
Add a helper that does both, and use it for search highlights, hover
and clicks.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If the inclusion gutter is shown, as it is in the focused main view
while building a custom patch, search matches are highlighted two
columns to the left of where they are. Hovering over a hyperlink
underlines the wrong columns, and a click acts on the cell two columns
to the right of the one that was clicked.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
A double-width character that starts in the last column of a view is
drawn over the view's frame. One that is scrolled halfway out to the
left is skipped, and the column it reaches into isn't drawn at all. The
draw loop clips cells against the edges of the view as if every cell
were one column wide.
A terminal can't show half of a double-width character. So draw a blank
in the column that is on screen, in the character's colors, and let the
selection highlight cover that column like any other.
A double-width character that starts in the last column of a view is
drawn over the view's frame. One that is scrolled halfway out to the
left is skipped, and the column it reaches into isn't drawn at all. The
draw loop clips cells against the edges of the view as if every cell
were one column wide.
A terminal can't show half of a double-width character. So draw a blank
in the column that is on screen, in the character's colors, and let the
selection highlight cover that column like any other.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If a double-width character starts in the last column of a view that
doesn't wrap, its second half is drawn over the view's frame. If one is
scrolled halfway out to the left, the column it still reaches into isn't
drawn at all. This column then has neither the selection highlight nor
the line's background. Both happen in every view that doesn't wrap: the
side panels, and the main view with gui.wrapLinesInDiffView set to
false.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If lazygit can't work out what diff lines it is supposed to act on when
staging a hunk (for example because of bugs like the one in #6099, or
maybe because of a misbehaving OSC-1717 diff renderer), it used to do
nothing and silently ignore the error. Now it shows an error popup to
the user in such a case, so that they can report the bug more easily.
Discarding lines from a commit's diff rewrites the commit with a
rebase. For this we look up the commit among the commits of the
current branch. If it isn't there, pressing the key does nothing. The
disabled reason only allows discarding in a diff of the commits panel,
so this shouldn't happen. If it does, the user should see it.
Show an error that names the commit instead.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
When we stage, discard or edit lines of the working tree's diff, we
read the file's diff again and look for the selected lines in it. If
none of them are there, nothing happens. The same goes for adding
lines of a commit's diff to a custom patch, or taking lines out of
it. This can happen if the file changed since its diff was shown, or
if we read the line numbers out of the diff on screen wrongly.
Show an error that names the file instead. As with a file that can't
be found, don't act on any file if the lines of one are missing.
Unlike the file check, this one happens after a new custom patch has
been started. If the error leaves that patch without any lines, reset
it, as we do when the last line is taken out of a patch.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If the path in the diff header of a selected line doesn't name a file
of the files panel, staging or discarding the line does nothing. The
command log shows "Apply patch", but nothing else happens, so the user
has nothing to go on when reporting it. Adding a line of a commit's
diff to a custom patch fails in the same silent way if the path
doesn't name a file of that diff. A diff renderer that names files
differently can cause this, and so can a bug in how we read the path,
like the one we had with diff.mnemonicPrefix.
Show an error that names the path instead, and do nothing else. If a
selection spans several files, don't act on the files we did find,
because that would do only part of what the user asked for. Do the
same for opening a line of a diff in its pull request.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
When staging, discarding or taking lines out of a custom patch spans
several files, we read the diff of a file and apply its patch before
we look at the next file. The next commits report an error if the
selected lines of a file can't be found. Without this change, the
files before it would already be acted on by then.
So find the lines in every file first, and only then apply anything.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If git fails to list the files of the diff that a custom patch is
built from, we carry on as if the diff had no files. Then we don't
know which files were renamed, added or deleted, and build the patch
from the wrong lines or without the file's creation or deletion.
Return the error instead, so that the user sees it.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The focused diff actions look up the file of a selected line in
different places. In the files panel, staging and discarding do it
per file while applying the patches, and editing a hunk does it for
the first line. For a commit's diff, adding lines to a custom patch or
discarding them from the commit does it only after the confirmation
prompt and after a new patch has been started. The next commits
report a line whose file can't be found as an error. For that, the
lookup has to happen once, before we log an action, ask for
confirmation or start a patch.
So let diffLineSelection group the selected lines by their file, in
the order the diff shows the files, and do the same for a commit's
diff in selectionByFile. A line whose file can't be found is still
skipped, as before.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
This fixes a regression in v0.66.0: when the `diff.mnemonicPrefix` git
config is true, staging or unstaging a diff hunk didn't work. It printed
"Apply patch" in the commands log, but would otherwise do nothing.
Fixes#6096.
If diff.mnemonicPrefix is set, pressing space on a line in the focused
main view does nothing. The command log shows "Apply patch", but the
line is not staged. Other commands that read a path out of the working
tree's diff go wrong as well, such as jumping to a file. Building a
custom patch from a commit's diff still works, because git uses
mnemonic prefixes only when one side of the diff is the index or the
working tree.
With this config, the paths in the working tree's diff start with i/
and w/ instead of a/ and b/. We only strip a/ and b/, so the path we
read out of the diff header is not a file of the files panel, and we
skip the line without a message.
Users who set the config want to see these prefixes, so keep them.
Strip the first component of the path instead, whatever it is. `git
apply` does the same by default, and ParseableDiffPrefixes makes sure
there is such a component.
A section without +++ and --- lines needs more than that, because we
find the new path on its "diff --git" line by searching for " b/".
Take the path from the "rename to" or "copy to" line instead where
there is one. Otherwise the two paths on the "diff --git" line are the
same. Split the line where the two halves match after stripping their
prefixes, like `git apply` does.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The "rename to" and "copy to" lines of a diff header spell a path the
same way as the other header lines, but without a prefix. The next
commit reads paths from these lines too.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If diff.mnemonicPrefix is set, pressing space on a line in the focused
main view does nothing.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If diff.srcPrefix and diff.dstPrefix are set (git 2.45 and later),
pressing space on a line in the focused main view does nothing. These
configs change the diff of a commit too, so the other commands that
read a path out of a diff go wrong as well.
The configs replace the a/ and b/ in front of the paths of a diff with
any string. We only know how to strip a/ and b/, so the paths we read
out of the diff header don't name a file.
We can't tell from the diff where such a prefix ends, so override the
two configs along with diff.noprefix.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If diff.srcPrefix and diff.dstPrefix are set, pressing space on a line
in the focused main view does nothing.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If diff.noprefix is set, pressing space on a line of a file under a
top-level directory named a or b does nothing. In a stash entry's diff,
the menu for jumping to a file shows such a file without its directory.
We read the path of a file out of the diff header and strip the a/ or
b/ in front of it. Most diff commands override diff.noprefix so that
this prefix is there, but the diff of the working tree and the diff of
a stash entry don't. With the config set, we strip the file's own
directory instead.
Use ParseableDiffPrefixes for these two commands too.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If diff.noprefix is set, the menu for jumping to a file of a stash
entry's diff leaves out the directory of a file under a top-level
directory named a or b.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
If diff.noprefix is set, pressing space on a line of a file under a
top-level directory named a or b does nothing.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Seven diff commands pass -c diff.noprefix=false so that the paths in
their output carry a prefix. The next commits use the override for
more commands and add more config to it, so give it a single home
first.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
