- **PR Description**
This makes it easier to copy diff hunks and paste them into code. We
only strip the prefixes if the copied lines are either all '+' or all
'-' (possibly including context lines), otherwise we keep them. We also
keep them when parts of a hunk header is included in the selection; this
is useful for copying a diff hunk and pasting it into a github comment,
for example.
A not-quite-correct edge case is when you select the '--- a/file.txt'
line of a diff header on its own; in this case we copy it as '--
a/file.txt' (same for the '+++' line). This is probably uncommon enough
that it's not worth fixing (it's not trivial to fix because we don't
know that we're in a header).
Fixes#3859.
Fixes#4511.
This makes it easier to copy diff hunks and paste them into code. We only strip
the prefixes if the copied lines are either all '+' or all '-' (possibly
including context lines), otherwise we keep them. We also keep them when parts
of a hunk header is included in the selection; this is useful for copying a diff
hunk and pasting it into a github comment, for example.
A not-quite-correct edge case is when you select the '--- a/file.txt' line of a
diff header on its own; in this case we copy it as '-- a/file.txt' (same for the
'+++' line). This is probably uncommon enough that it's not worth fixing (it's
not trivial to fix because we don't know that we're in a header).
- **PR Description**
In the commits list of an interactive rebase, the gap between the rebase
todo column and the author column was two instead of one. Remove the
extra space to make this gap the same as for all other columns.
This is very old; I can only guess that this was added at a time where today's
list column handling wasn't in place yet, so the space was needed to separate
columns. This now causes a gap of two spaces between the rebase todo column and
the author column, which I'm sure wasn't intended. Funny that I never noticed.
- **PR Description**
This is very similar to what we are doing for staging or discarding
hunks in the Files panel (see #4235). Git doesn't allow applying patches
with a zero context size (unless you use the --unidiff-zero option,
which is discouraged).
Fixes#4521.
This is very similar to what we are doing for staging or discarding hunks in the
Files panel. Git doesn't allow applying patches with a zero context size (unless
you use the --unidiff-zero option, which is discouraged).
Fish shell does not support "&&" and "||" operators like
POSIX-compatible shells. Instead, it uses a different syntax structure
based on begin/end and if/else.
This caused existing lazygit nvim-remote integration templates to break
when fish was the user's default shell.
This commit adds explicit fish shell detection using the FISH_VERSION
environment variable, and provides fish-compatible templates that
correctly handle launching Neovim or sending remote commands via $NVIM.
Fixes behavior where edits would not open in a new Neovim tab or line
navigation would fail when $NVIM was set.
Ensures smoother editing experience for users running fish shell
(supported since Nov 2012 with FISH_VERSION).
Fish shell does not support "&&" and "||" operators like
POSIX-compatible shells. Instead, it uses a different syntax structure
based on begin/end and if/else.
This caused existing lazygit nvim-remote integration templates to break
when fish was the user's default shell.
This commit adds explicit fish shell detection using the FISH_VERSION
environment variable, and provides fish-compatible templates that
correctly handle launching Neovim or sending remote commands via $NVIM.
Fixes behavior where edits would not open in a new Neovim tab or line
navigation would fail when $NVIM was set.
Ensures smoother editing experience for users running fish shell
(supported since Nov 2012 with FISH_VERSION).
**PR Description**
This PR updates the README to include installation instructions for
Debian.
* Renames the "Ubuntu" section to "Debian and Ubuntu"
* Adds the `sudo apt install lazygit` for Debian Trixie, Sid, and Ubuntu
25.10 and later
* Keeps the manual installation method for Debian Bookworm, Ubuntu 25.04
and earlier
This helps Debian and Ubuntu users install lazygit using either apt or
manual download, depending on the distribution version.
**Affected files**
* Documentation
* `README.md`: Renames the "Ubuntu" section to "Debian and Ubuntu" and
adds Debian installation instructions
**Requirements fulfilled by this PR**
* [x] Cheatsheets are up-to-date (run `go generate ./...`)
* [x] Code has been formatted (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting))
* [x] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
- **PR Description**
Allow pressing `{`, `}`, `(`, and `)` to change the diff context size
and rename threshold when the main view is focused. This was forgotten
in #4429.
- **PR Description**
Add a new command "Move commits to new branch" (bound to `N` by
default), which is useful if you have just started some new work, you
already made some commits, and then you realize that you forgot to
create a new branch first, accidentally making those commits on main or
whichever other feature branch you happened to be on.
If you made those commits on main, you are prompted for a branch name
for the new branch, and then it creates the new branch right there and
hard-resets main to where it was. If you made them on another feature
branch though, you are first given the choice whether you want to create
the new branch from main, or keep it stacked on that other feature
branch. Then it prompts you for the name and proceeds as above.
Inspired by Magit's
[magit-branch-spinoff](https://magit.vc/manual/magit/Branch-Commands.html#index-b-s)
command.
The conditions under which the command is available are rather
restrictive: the current branch must have an upstream, it must not be
behind its upstream, but it must be ahead of it (otherwise there
wouldn't be any commits to move, and you might as well just create a new
branch normally).
The long story: I want to call this function from RefsHelper; however, I can't
make WorkingTreeHelper a field of RefsHelper because RefsHelper is already a
field in WorkingTreeHelper, so that would be a circular dependency.
The shorter story: there's really little reason to have to instantiate a helper
object in order to call a simple function like this. Long term I would like to
get to a state where a lot more of these helper functions are free-standing, and
you pass in the data they need.
While at it, simplify the implementation of AnyStagedFiles and AnyTrackedFiles
to one-liners.
It's the same, really, except that GetCheckedOutRef() does a check if any
branches exist and returns nil if not. Since we are accessing the returned
branch unconditionally without checking for nil, it seems this check is not
needed here. (The functions we are touching here are called from handlers that
are guarded with itemSelected or singleItemSelected, so we know that at least
one branch exists.)
The goal is to get rid of the dependency to refsHelper.
- **PR Description**
Add a new user config for auto-forwarding branches after fetching; by
default this is set to "onlyMainBranches", but it can be set to
"allBranches" to extend it to feature branches too, or to "none" to
disable it.
This is used both when fetching manually by pressing `f` in the files
panel, and for automatic background fetching.
- **PR Description**
This adds a new `0` keybinding to the side panels that focuses whatever
main view is currently displayed, with the goal of making it easier to
scroll the main view (using the normal navigation keys `,` `.` `<` `>`),
and being able to search the main view using `/`.
Alternatively to pressing `0` you can also click the main view to focus
it. Note that previously it was possible to go directly to the staging
panel by clicking in the main view when a file was selected; this now
takes a double click, because the first click just focuses the main
view, but you can go to staging from there by clicking again.
I'm reasonably happy with the overall behavior, but it takes some
getting used to, so we'll want to test this for a while to see if it
doesn't make the focus handling too confusing.
Fixes#3988.
And only while the task is running.
This avoids accumulating lots of blocked goroutines when scrolling a view down
more than 1024 times (the capacity of the readLines channel).
In this commit this is only possible by pressing '0' in a side panel; we'll add
mouse clicking later in the branch.
Also, you can't really do anything in the focused view except press escape to
leave it again. We'll add some more functionality in a following commit.
Previously we would render the diff for a directory to the main/secondary pair,
but a diff for a file to the staging/stagingSecondary pair. (And similar for
commit files: main/secondary for directories, but
patchBuilding/patchBuildingSecondary for files.)
I always found this confusing and couldn't really understand why we are doing
this; but now it gets in my way because I want to attach a controller to
main/secondary so that they can be focused. So change it to always use the main
context pair for everything we render from a side panel.
- **PR Description**
During interactive rebase, or when stopping with conflicts in a
cherry-pick or revert, show section headers for the todo items and the
actual commits. This makes it much clearer where the current head commit
is. Get rid of the "<-- YOU ARE HERE" marker that we would previously
show; it is no longer needed. (We still show the "<-- CONFLICT" marker
though.)
For example:
```
╭─[4]─Commits - Reflog───────────────────────────╮
│--- Pending rebase todos --- │
│6562f903 pick CI commit 03 │
│--- Commits --- │
│56a04448 CI ◯ commit 02 │
│6d0c0e41 CI ◯ commit 01 │
```
