When replacing the naked return with a `return result`, the linter starts to
complain about "return copies lock value: sync/atomic.Int32 contains
sync/atomic.noCopy". I suspect this is also a problem when using a naked return,
and the linter just doesn't catch it in that case. Either way, it's better to
use a pointer to ensure that the atomic is not copied.
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
When a new enough gofumpt version is used (v0.9.0 or later), it suports the
`ignore` directive that we just added, so the workaround is no longer needed.
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
This will put whatever git's default merge variant is as the first menu
item, and add a second item which is the opposite (no-ff if the default
is ff, and vice versa). Which one is the default depends on whether a
fast-forward merge is possible, and whether users have set git's
`merge.ff` config or lazygit's `git.merging.args` config.
If users prefer to always have the same option first no matter whether
it's applicable, they can make ff always appear first by setting git's
`merge.ff` config to "true" or "only", or by setting lazygit's
`git.merging.args` config to "--ff" or "--ff-only"; if they want no-ff
to appear first, they can do that by setting git's `merge.ff` config to
"false", or by setting lazygit's `git.merging.args` config to "--no-ff".
Which of these they choose depends on whether they want the config to
also apply to other git clients including the cli, or only to lazygit.
Closes#4091.
This will put whatever git's default merge variant is as the first menu item,
and add a second item which is the opposite (no-ff if the default is ff, and
vice versa).
If users prefer to always have the same option first no matter whether it's
applicable, they can make ff always appear first by setting git's "merge.ff"
config to "true" or "only", or by setting lazygit's "git.merging.args" config to
"--ff" or "--ff-only"; if they want no-ff to appear first, they can do that by
setting git's "merge.ff" config to "false", or by setting lazygit's
"git.merging.args" config to "--no-ff". Which of these they choose depends on
whether they want the config to also apply to other git clients including the
cli, or only to lazygit.
- Squash and FastForwardOnly are mutually exclusive, and instead of asserting
this at runtime, model the API so that they can't be passed together.
- FastForwardOnly is unused, so remove it; however, we are going to need --ff
and --no-ff in the next commit, so add those instead.
- Instead of putting the enum into the MergeOpts struct, replace the struct by
the enum. We can reintroduce the struct when we add more arguments, but for
now it's an unnecessary indirection.
I found that PR status becomes green even if no label added when we use
`Update branch` on GitHub PR page.
So I added `synchronize` event to the hooks of `Check Required Labels`.
Stashing doesn't affect submodules, so if you have a working copy that
has out-of-date submodules but no other changes, and then you revert or
paste a commit (or invoke one of the many other lazygit commands that
auto-stash, e.g. undo), lazygit would previously try to stash changes
(which did nothing, but also didn't return an error), perform the
operation, and then pop the stash again. If no stashes existed before,
then this would only cause a confusing error popup ("error:
refs/stash@{0} is not a valid reference"), but if there were stashes,
this would try to pop the newest one of these, which is very undesirable
and confusing.
Stashing doesn't affect submodules, so if you have a working copy that has
out-of-date submodules but no other changes, and then you revert or paste a
commit (or invoke one of the many other lazygit commands that auto-stash, e.g.
undo), lazygit would previously try to stash changes (which did nothing, but
also didn't return an error), perform the operation, and then pop the stash
again. If no stashes existed before, then this would only cause a confusing
error popup ("error: refs/stash@{0} is not a valid reference"), but if there
were stashes, this would try to pop the newest one of these, which is very
undesirable and confusing.
This happened to a few users after updating macOS to version 15.7.1, and
apparently a reboot fixes it, so suggest this in the error message.
Closes#4924
Adds a config option that disables the confirmation for switching to a
worktree when trying to check out a branch that is checked out in that
other worktree.
Fixes#4938.
Lazygit would become unresponsive when cherry-picking a commit that
becomes empty at the destination. There are two ways this can happen:
one where a cherry-picked commit simply becomes empty "by itself",
because the change is already present on the destination branch (this
was only a problem with git versions older than 2.45), and another where
the cherry-pick stops with conflicts, and the user resolves them such
that no changes are left, and then continues the cherry-pick. This would
still fail even with git 2.45 or later. The fix is the same for both
cases though.
Fixes#4763.
I can't do my usual "add the tests first, with EXPECTED/ACTUAL sections that
document the bug" method here, because the tests would hang without the bug
being fixed.
We need two different tests here: one where a cherry-picked commit simply
becomes empty "by itself", because the change is already present on the
destination branch (this was only a problem with git versions older than 2.45),
and the other where the cherry-pick stops with conflicts, and the user resolves
them such that no changes are left, and then continues the cherry-pick. This
would still fail even with git 2.45 or later. The fix is the same for both cases
though.
The tests show that the selection behavior after skipping an empty cherry-picked
commit is not ideal, but since that's only a minor cosmetic problem we don't
bother fixing it here.
Whenever git returns the error "The previous cherry-pick is now empty", we would
previously continue the rebase; this works for rebase because it behaves the
same as "git rebase --skip" in this case. That's not true for cherry-pick
though; if you continue a cherry-pick where the current commit is empty, it will
return the same error again, causing lazygit to be stuck in an endless loop.
Fix this by skipping instead of continuing; this shouldn't make a difference for
rebase, but works for cherry-pick.
Theoretically we could have a similar problem for revert (if you are trying to
revert a commit that has already been undone through some other means); this
should then be fixed in the same way with this change. However, the change is
not relevant for revert because git returns a different error in this case.
When focusing the main view, going into full screen mode by pressing '+'
twice, and then opening the search prompt ('/') or a menu (e.g. '?' or
':'), the full screen display would switch to the focused side panel.
Fix this by always excluding popups from the window arrangement logic.
No popup should ever have any influence on how the views beneath it are
laid out.
Addresses [this detail
aspect](https://github.com/jesseduffield/lazygit/issues/1113#issuecomment-3206883422)
of #1113.
When focusing the main view, going into full screen mode by pressing '+' twice,
and then opening the search prompt ('/') or a menu (e.g. '?' or ':'), the full
screen display would switch to the focused side panel.
Fix this by always excluding popups from the window arrangement logic. No popup
should ever have any influence on how the views beneath it are laid out.
Allow configuring an array of pagers, and cycling through them with the
`|` key (mnemonic: we are piping the output through something). I find
this useful for switching between delta (which I prefer most of the
time) and difftastic (which occasionally produces better output for
certain kinds of changes). It could also be used to switch between delta
in inline mode and in side-by-side mode.
This is an object that is owned by Gui, is accessible through GuiCommon.State(),
and also passed down to GitCommand, where it is mostly needed. Right now it
simply wraps access to the Git.Paging config, which isn't very exciting, but
we'll extend it in the next commit to handle a slice of pagers (and maintain the
currently selected pager index), and doing this refactoring up front allows us
to make that change without having to touch clients.
This is likely to do bad things; for example, if the prompt is the shell
command prompt, then we would run into what looks like a deadlock bug in
tcell. In other cases, the characters in the following lines might be
treated as random keybindings after the prompt is confirmed; this is
very similar to #4234.
In this case, it seems the best we can do is to simply swallow the line
feeds. The entire pasted text will then appear as a single long line in
the prompt, and hopefully the user knows that they can use ctrl-u to
delete it again. If not, they will probably just hit esc to close the
prompt.
Fixes#4954.
This is likely to do bad things; for example, if the prompt is the shell command
prompt, then we would run into what looks like a deadlock bug in tcell. In other
cases, the characters in the following lines might be treated as random commands
after the prompt is confirmed.
Fixes#4890
When Git is configured with status.renames=copies, it can produce
status codes starting with "C" (copy) in addition to "R" (rename).
The file loader was only checking for "R" prefixes, causing copy
operations to be parsed incorrectly and breaking file staging.
This fix extends the status parser to handle both "R" and "C"
prefixes, ensuring proper support for Git's copy detection feature.
Fixes file staging issues when using status.renames=copies configuration.
We want to switch to have paragraphs consistently on one line, and auto-wrap
them automatically when generating Config.md.
The changes to Config.md in this commit are temporary.
Our logic to decide if a file needs to be checked out from the previous
commit or deleted because it didn't exist in the previous commit didn't
work for submodules. We were using `git cat-file -e` to ask whether the
file existed, but this returns an error for submodules, so we were
always deleting those instead of reverting them back to their previous
state.
Switch to using `git ls-tree -- file` instead, which works for both
files and submodules.
Fixes#4932.
Our logic to decide if a file needs to be checked out from the previous commit
or deleted because it didn't exist in the previous commit didn't work for
submodules. We were using `git cat-file -e` to ask whether the file existed, but
this returns an error for submodules, so we were always deleting those instead
of reverting them back to their previous state.
Switch to using `git ls-tree -- file` instead, which works for both files and
submodules.
It works for submodules too.
Also, pass file name and file content explicitly; the existing tests don't care
about these, but when writing tests that do, it makes them easier to understand.
Doesn't make a difference currently, since the title is either StatusTitle when
the dashboard is showing, or LogTitle when one of the branch logs is showing.
This is going to change in the next commit, though.
When cycling to the last branch log command, and then editing the config to
remove one or more log commands, lazygit would crash with an out of bounds panic
when returning to it. Fix this by resetting the log index to 0 when it is out of
bounds. (I think resetting to 0 is better than clamping, although it doesn't
matter much.)
I know that uint was chosen to document that it can't be negative (not sure why
the "8" was chosen, though). That's pointless in languages that don't enforce
this though: you can subtract 1 from uint8(0) and you'll get something that
doesn't make sense; that's not any better than getting -1. I'm not a fan of
using unsigned types in general (at least in languages like go or C++), and they
usually just make the code more cumbersome without real benefits.
