Previously we would hide it if no onSwitchToEditor function was set; that was
from a time when <c-o> was bound directly to the switch-to-editor command. Now
it is bound to showing a menu, and that menu is always available even if no
onSwitchToEditor function is set. (We rather need to disable the switch to
editor item _within_ that menu, see next commit.)
- **PR Description**
Hi, I'm happy using `lazygit` from quite a while. I've decided to give
back to community fraction of my time. I'm native polish speaker, and
seen that polish translation have some gaps.
I've added missing translation for polish language and improved existing
one. I've followed technical jargon used on
https://git-scm.com/book/pl/v2/
For easier diff comparison and feature maintenance, I've ordered keys to
be in same order as those in `english.go`
By default we now search for substrings; you can search for multiple
substrings by separating them with spaces. Add a config option
`gui.filterMode` that can be set to 'fuzzy' to switch back to the
previous behavior.
Addresses #3373.
For die-hard fuzzy-searching fans it's probably in the way, so taking it out
makes fuzzy filtering work better. For substring filtering it always retains the
sort order anyway.
By default we now search for substrings; you can search for multiple substrings
by separating them with spaces. Add a config option gui.filterMode that can be
set to 'fuzzy' to switch back to the previous behavior.
It sorts them already, so it's unnecessary. In the next commit we use this same
code for substring searching too, and in that case we don't want to sort because
sorting is by Score, but we don't even fill in the score for substring
searching.
- **PR Description**
When checking out a remote branch by name, ask the user how they want to
check it out; the choices are to create a new local branch that tracks
the remote, or a detached head.
This is an alternative to #3371, and fixes#2312.
Lazygit has two ways to decide whether it needs to ask the user to
force-push:
1. if it knows ahead of time that the push will fail because the branch
has diverged, by looking at the incoming/outgoing information that it
shows as ↑3↓7.
2. by examining the error that comes back when the push has failed.
The second situation should happen only rarely, because lazygit fetches
every minute by default, so the ↑3↓7 information is usually up to date.
It might not be if the user turned off auto-fetch (or increased the
auto-fetch interval). However, in this case it's almost always harmful
to prompt the user to force-push, because we know that the reason for
diverging is that something was pushed to the remote, and we would wipe
it out by force-pushing. In such a situation, the more likely user
action is to pull the remote changes and then push normally again.
So just remove the second prompt, and replace it by a better error
message when we detect that updates were rejected remotely.
A little bit of history archeology reveals that the second prompt was
added at a time where we didn't have the first one yet, so at that time
it made sense to have it; but when the first prompt was added, we should
have removed the second.
Lazygit has two ways to decide whether it needs to ask the user to force-push:
1. if it knows ahead of time that the push will fail because the branch has
diverged, by looking at the incoming/outgoing information that it shows as ↑3↓7.
2. by examining the error that comes back when the push has failed.
The second situation should happen only rarely, because lazygit fetches every
minute by default, so the ↑3↓7 information is usually up to date. It might not
be if the user turned off auto-fetch (or increased the auto-fetch interval).
However, in this case it's almost always harmful to prompt the user to
force-push, because we know that the reason for diverging is that something was
pushed to the remote, and we would wipe it out by force-pushing. In such a
situation, the more likely user action is to pull the remote changes and then
push normally again.
So just remove the second prompt, and replace it by a better error message when
we detect that updates were rejected remotely.
A little bit of history archeology reveals that the second prompt was added at a
time where we didn't have the first one yet, so at that time it made sense to
have it; but when the first prompt was added, we should have removed the second.
- **PR Description**
Previously it wasn't possible to move an update-ref entry up or down
using ctrl-j and ctrl-k, or to delete an update-ref entry. For moving, a
work-around was to move the surrounding commits instead, but it's still
nice to be able to do it directly. Deleting is very much necessary
though, since there are situations where git adds the update-ref entries
but they are not wanted; one example is if you want to make a copy of a
branch and rebase to a different place, without the original branch
following it. (There's a long discussion about this
[here](https://public-inbox.org/git/adb7f680-5bfa-6fa5-6d8a-61323fee7f53@haller-berlin.de/).)
Update-ref todos can't be set to "drop" like other todos, because they
have no sha associated with them, so we need to delete them immediately.
We show a confirmation before doing that, because you'd have to abort
the rebase if you do it accidentally.
We allow range selecting normal todos and update-ref todos at the same
time; in that case, we delete all the update-ref todos and set all the
other ones to "drop". Not that this is an absolutely necessary feature,
but it wasn't hard to do.
So far, the only situation where we called SetSelectionRangeAndMode was one
where the range could only get larger (in startInteractiveRebaseWithEdit, in
which case update-ref todos can be inserted by the rebase). However, in the last
commit we introduced a new call site where the range can get smaller, including
being reduced to a single item. Since this is indistinguishable from a single
selection, set the mode to none in this case; without this, hitting escape would
seemingly do nothing because it collapses the empty range selection.
- **PR Description**
Remember which version of lazygit the user was last running, and show a
list of breaking changes since that version (if any) if the user
upgraded to a newer version.
It's a little unobvious how to test this manually, because we don't show
the popup for developer builds. You'll have to build with something like
`go build -ldflags="-X 'main.version=0.41.0'"` in order to test it.
This is an extremely stripped down version of #3261.
- Adds Co-Author support to commit menu (`<C-o>` by default)
- `e` Opens up the commit message in your editor
- `c` Lets you add a co author to your commit
- Cleans up and amend commit attribute menu related code
- **PR Description**
Add new config settings `git.commit.autoWrapCommitMessage` (default
true) and `git.commit.autoWrapWidth` (default 72), which allow automatic
as-you-type wrapping of the commit message body to the specified width.
There are occasional situations where this wrapping is in the way, for
example when you need to have longer lines in the message for some
reason (perhaps because you have a very wide ASCII art picture or
table), and you'll have to resort to switching to the editor in that
case. However, in my experience these cases are quite rare.
... and when recalling a commit message from an old commit by pressing up-arrow.
This is necessary because committing turns our soft line breaks into real ones,
but when rewording we want to turn them back into soft ones again, so that it's
possible to insert words at the beginning of a paragraph and have everything
rewrap nicely.
This is only a best effort; the algorithm only removes those hard line breaks
that can be removed without changing the way the message looks. This works well
when the previous commit message was wrapped at the same width, which for most
users should be the most common case; but if it wasn't, the result is not great.
Specifically, if the old wrap width was smaller, some hard line breaks just
won't be removed; if it was wider though, you'll get an unpleasant comb effect
with alternating long and short lines. In such a case it's best to switch to the
editor and use whatever wrapping features you have there (e.g. alt-Q).
I have seen some commit messages that contain CRLF instead of just LF; I'm not
sure if these were created by a broken git client, but they exist, so we need to
deal with them. Editing them when rewording a commit sort of works, but is a
little strange; the \r characters are invisble, so you need an extra arrow key
press to skip over them.
In the next commit we are going to add more logic related to line breaks, and it
is getting confused by the \r, so it is becoming more important to fix this. The
easiest fix is to normalize the line endings right after loading.
- **PR Description**
Keep the same commit selected after squashing fixup commits, and after
creating fixup commits.
Edge case: it is now possible to have a range of commits selected when
squashing fixups (by using the "in current branch" version of the
command), and in that case we don't bother preserving the range. It
would be possible, but would require more code, and I don't think it's
worth it, so I'm simply collapsing the range in that case.
This should arguably have been done in b133318b40 already; it's becoming more
important now because we're going to extend the common code with more logic in
the next commit.
We have such a test already (squash_fixups_above_first_commit.go), but it can't
be used for what we want to check here, because it uses the first commit, and we
can't move down from there. So create a new one that basically does the same
thing, but for a commit in the middle. The focus of this new test is to check
how the selection behaves; as you can see, there is a problem both when creating
a fixup and when squashing fixups. We'll address these separately in the next
commits.
- **PR Description**
It is now possible to select a range of commits (while not in a rebase),
and hit "e" to edit them all. This starts a rebase on the bottom-most
commit of the range, and sets all the selected commits to "edit"
(skipping merge commits, because they can't be edited).
It starts a rebase on the bottom-most commit of the range, and sets all the
selected commits to "edit" (skipping merge commits, because they can't be
edited).
In most real-world scenarios, name and path are usually the same. They don't
have to be though, and it's important to make sure we use the right one when
passing arguments to git commands, so change the tests to have different name
and path.
When doing a non-interactive rebase using a version of git earlier than
2.26, or by explicitly calling `git -c rebase.backend=apply rebase`,
lazygit can display the pending todos by parsing the numbered patch
files in `.git/rebase-apply/`. Unfortunately, support for this has been
broken for more than three years because of the change in 682db77401
(the string literal "normal" should have been changed to
REBASE_MODE_NORMAL instead of REBASE_MODE_MERGING).
It's not an important bug since you can only get into this situation by
doing a rebase outside of lazygit, and then only with a pretty old git
version or by using very uncommon git options. So instead of fixing the
bug, just remove the code.
When doing a non-interactive rebase using a version of git earlier than 2.26, or
by explicitly calling `git -c rebase.backend=apply rebase`, lazygit can display
the pending todos by parsing the numbered patch files in `.git/rebase-apply/`.
Unfortunately, support for this has been broken for more than three years
because of the change in 682db77401 (the string literal "normal" should have
been changed to REBASE_MODE_NORMAL instead of REBASE_MODE_MERGING).
It's not an important bug since you can only get into this situation by doing a
rebase outside of lazygit, and then only with a pretty old git version or by
using very uncommon git options. So instead of fixing the bug, just remove the
code.
- **PR Description**
Fix a bug where merging would fail with an error message when you try to
put more than one argument in the `git.merging.args` config. This broke
with 25f8b0337e.
Fixes#3334.
This makes it possible again to pass multiple arguments, for example
"--ff-only --autostash". This won't work correctly if you want to use
an argument that contains a space, but it's very unlikely that people
will want to do that, so I think this is good enough.
- **PR Description**
When doing an interactive rebase of a stack of branches with the
`rebase.updateRefs` git config set to true, you get `update-ref` todos
between the "pick" items. In this situation we would still show the
branch head icon for each pick item that used to be the head of a
branch. This is confusing, especially when you want to move a new commit
to the head of a branch in the middle of the stack. Consider the
following scenario:
<img width="410" alt="image"
src="https://github.com/jesseduffield/lazygit/assets/1225667/438b7157-e51e-48fb-95a9-b67039a7ad30">
Here we have made a new commit at the top of the stack, entered
interactive rebase, and moved the commit down to the head of the second
branch. Now it sits between the commit that shows the branch icon of the
second branch, and the update-ref item for the second branch. This is
super confusing, and it's simply better to not show branch icons for
pick entries. That's what this PR does.
We do show the icons if the `rebase.updateRefs` config is off, because
otherwise there would be no indication of where the branches start and
end. Of course, changing anything in this case will destroy the stack,
so maybe it would be better to hide the icons in this case too to make
this more obvious. I'm unsure about that.
The additional branch head icon is more confusing than useful in this situation.
The update-ref entries show very clearly where the branch heads will go when
continuing the rebase; the information where the branch heads used to be before
the rebase is not really needed here, and just makes the display more confusing.
I'm not adding more tests here because the changes to the existing tests
demonstrate the change clearly enough.
The helix binary seems to be called "helix" on some distributions (e.g. Arch),
but "hx" on others (e.g. Fedora). Provide presets for both, so that
auto-detection from $EDITOR works.
- **PR Description**
A common workflow for me is to create a fixup commit from only some of
my current changes; to do that, I enter a file, stage a few hunks, and
then want to invoke ctrl-f to find the base commit for these changes.
Currently I need to esc back to the files panel in order to do that;
it's more convenient to be able to do this right from the staging panel.
Labelled as "ignore-for-release" because the ctrl-f feature has only
been added after the last release, so no release notes needed for this
change.
A common workflow for me is to create a fixup commit from only some of my
current changes; to do that, I enter a file, stage a few hunks, and then want to
invoke ctrl-f to find the base commit for these changes. Currently I need to esc
back to the files panel in order to do that; it's more convenient to be able to
do this right from the staging panel.
Calling "git reset" on the command line (without further arguments)
defaults to --mixed, which is reason enough to make it the default for
us, too.
But I also find myself using --mixed more often than --soft. The main
use case for me is that I made a bunch of WIP commits, and want to turn
them into real commits when I'm done hacking. I select the last commit
before the WIP commits and reset to it, leaving all changes of all those
commits in the working directory. Since I want to start staging things
from there, I prefer those modifications to be unstaged at that point,
which is what --mixed does.
Calling "git reset" on the command line (without further arguments) defaults to
--mixed, which is reason enough to make it the default for us, too.
But I also find myself using --mixed more often than --soft. The main use case
for me is that I made a bunch of WIP commits, and want to turn them into real
commits when I'm done hacking. I select the last commit before the WIP commits
and reset to it, leaving all changes of all those commits in the working
directory. Since I want to start staging things from there, I prefer those
modifications to be unstaged at that point, which is what --mixed does.
- **PR Description**
I encountered the problem that I couldn't extract changes into a new
commit because I had difftastic as an external git tool configured.
Add `diff.noprefix=false` config Option and also specify `--no-ext-diff`
when doing the `git diff` after applying a patch.
This fixes#3107.
Though, there might be other config options that can cause problems, but
fixing these common cases should be an improvement nevertheless.
For some lists it is useful to keep the same sort order when filtering (rather
than sorting by best match like we usually do). Add an optional function to
FilteredList to make this possible, and use it whenever we show lists of things
sorted by date (branches, stashes, reflog entries), as well as menu items
because this allows us to keep the section headers in the keybindings menu,
which is useful for understanding what you are looking at when filtering.
After #3283 we need to read more lines initially so that the scrollbar
goes to its minimal height of 1 for long diffs. Without this, it would
start with a height of 2 and then become smaller after you scroll down
half the window height.
It does mean that we need to read twice the number of lines initially
(up to the limit of 5000). I think it's worth it, I find the incorrect
initial size confusing.
After #3283 we need to read more lines initially so that the scrollbar goes to
its minimal height of 1 for long diffs. Without this, it would start with a
height of 2 and then become smaller after you scroll down half the window
height.
- **PR Description**
Fix order problems when saving custom commands history
This fixes two problems:
- each time the custom commands panel was opened, the history of commands would
be shown in reversed order compared to last time. (The reason is that
lo.Reverse modifies the slice in place rather than just returning a new,
reversed slice.)
- when executing a previous command again (either by typing it in again, or by
picking it from the history), it should move to the beginning of the history,
but didn't.
We fix this by storing the history in reversed order (as the user sees it in
the panel), this makes the logic simpler. We just have to prepend rather
than append newly added commands now.
While this is theoretically a breaking change, it's not worth bothering because
the order was wrong for existing users in 50% of the cases anyway.
This fixes two problems:
- each time the custom commands panel was opened, the history of commands would
be shown in reversed order compared to last time. (The reason is that
lo.Reverse modifies the slice in place rather than just returning a new,
reversed slice.)
- when executing a previous command again (either by typing it in again, or by
picking it from the history), it should move to the beginning of the history,
but didn't.
We fix this by storing the history in reversed order (as the user sees it in
the panel), this makes the logic simpler. We just have to prepend rather
than append newly added commands now.
While this is theoretically a breaking change, it's not worth bothering because
the order was wrong for existing users in 50% of the cases anyway.
- **PR Description**
This fixes two loosely related problems with `update-ref` todos:
1. Panic when hitting enter on an `update-ref` item
2. When selecting an `update-ref` item and then triggering a refresh,
there was a bogus error message `fatal: ambiguous argument '': unknown
revision or path not in the working tree.`
Scenario:
- show the files of a commit, escape out of it again
- start an interactive rebase of a stack of branches, with the rebase.updateRefs
git config set to true
- select one of the update-ref todos
- trigger a refresh (either manually or by bringing lazygit's terminal window to
the front)
This results in an error message "fatal: ambiguous argument '': unknown revision
or path not in the working tree."
Fix this by putting another band-aid on the check for the commit files refresh.
This is the easiest way to fix the problem, but I don't think it's the best one.
We shouldn't be refreshing the commit files context at all if it isn't visible,
because it's pointless; there's no way to switch to it again except by calling
viewFiles again with a specific ref. But I'm too lazy too figure out how to do
that right now.
Cherry-picking merge commits is currently not supported because of the
way copy/pasting is currently implemented. Disable the command with a
proper error message if the user tries to copy a merge commit, instead
of running into the confusing error message that git would otherwise
give, see #1374.
While we're at it, disable it also when trying to copy an "update-ref"
todo, which doesn't make sense.
Stefan Haller
