The folder custom_commands contained tests for both custom commands (the ones
you configure in config.yml) and shell commands (the ones you execute at the ":"
prompt). I always found this confusing, so separate these into two different
folders.
- **PR Description**
The green/red bars for added/deleted lines in delta wouldn't extend to
the right edge of the view, but end after the last printable character.
This was broken before, and fixed in #1386 two years ago, but then it
broke again in v0.42 because of #3687.
- **PR Description**
When using the panel jump keybindings (`1` through `5` by default), and
the target panel is already the active one, go to the next tab instead.
- **PR Description**
When executing an interactive custom command, use the user's shell
rather than "bash", and pass the -i flag. This makes it possible to use
shell aliases or shell functions which are not available in
non-interactive shells.
In previous attempts to solve this, concerns were brought up: [this
one](https://github.com/jesseduffield/lazygit/pull/2096#issuecomment-1257072541)
is addressed by using the interactive shell only for custom commands but
not anything else. [This
one](https://github.com/jesseduffield/lazygit/pull/2096#issuecomment-1343341795)
is a little dubious and unconfirmed, so I'm not very worried about it.
Supersedes #2096 and #3299. Fixes#770, #899, and #1642.
Also, use the user's shell (from the SHELL env variable) instead of bash. Both
of these together allow users to use their shell aliases or shell functions in
the interactive command prompt.
- **PR Description**
When switching from a branch with fewer commits than fit in the commits
panel to another branch with even fewer commits, the last few commits of
the old branch were still drawn at the bottom.
Fixes#3778.
- **PR Description**
The extension icon map contain all extensions on lowercase, when a file
don't have extension on lowercase the string don't match and icon is not
assigned.
- **PR Description**
Fixes#3740
As explained in the issue, 7a67096 moved some code around that caused a
call to `GetRepoPaths` to occur before `setupApp`, which usually handles
the scenario where we are not in a git directory. `GetRepoPaths` returns
an error if the path isn't a git repository, which caused the app to
exit before we reached `setupApp`.
When starting up lazygit, we ignore (and log) the error returned by
`GetRepoPaths`, and continue instead of exiting early. This allows us to
reach the step where we follow the user's `notARepository` config entry.
- **PR Description**
For some custom commands, they can be used in multiple contexts. But for
now, if we want to do this, we should copy and paste the same config
times and times with just a different **context**.
Related issue: #3759
This PR makes it possible to use multiple contexts in the `context` field of
`customCommand`, separated by comma.
Also check for squash! and amend! (these are all anchored to the beginning of
the subject), and WIP and DROPME for good measure (but only if they occur in the
first line, otherwise it wouldn't let me merge this very commit :)
My local git is not compiled with PCRE support, so using -E makes it easier for
me to test the script locally. And -E is good enough for the simple matching we
want to do here.
- **PR Description**
Fix a regression (introduced with #3649) that broke language
auto-detection. When starting lazygit with the `gui.language` config set
to "auto" (which is the default), lazygit would fail to start if the
LANG environment is set to one of our supported languages.
For example:
```
$ export LANG=nl_NL
$ lazygit
2024/07/13 11:43:03 open translations/nl-NL.json: file does not exist
```
Fixes#3743
- **PR Description**
Currently if a branch name does not match a regex pattern defined in the
config.yaml (commitPrefix/es) the commit message box is populated with
the branch name as is - this does not match expectations. A prefix
should only be added if there is a match on the regex pattern.
This PR seeks to change that by checking for a match before calling
ReplaceAllString - see Issue #3695
- **Please check if the PR fulfills these requirements**
* [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] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [-] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [-] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
### Overview
| Current Behaviour | New Behaviour |
|--|--|
| Local branches will **always** track the remote branches they were
created from. | Local branches will track the remote branches they were
created from **only if their names match**. |
### Description
The current behaviour when creating a new branch off of a remote branch
is to always track the branch it was created from.
For example, if a branch 'my_branch' is created off of the remote branch
'fix_crash_13', then 'my_branch' will be tracking the remote
'fix_crash_13' branch.
It is common practice to have both the local and remote branches named
the same when the local is tracking the remote one. Therefore, it is
reasonable to expect that 'my_branch' should not track the remote
'fix_crash_13' branch.
The new behaviour when creating a new branch off of a remote branch is
to track the branch it was created from only if the branch names match.
If the branch names DO NOT match then the newly created branch will not
track the remote branch it was created from.
For example, if a user creates a new branch 'fix_crash_13' off of the
remote branch 'fix_crash_13', then the local 'fix_crash_13' branch will
track the remote 'fix_crash_13' branch.
However, if the user creates a new branch called 'other_branch_name' off
of the remote branch 'fix_crash_13', then the local 'other_branch_name'
branch will NOT track the remote 'fix_crash_13' branch.
- **Please check if the PR fulfills these requirements**
* [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] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [ ] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [ ] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
No content changes yet, because nobody has edited anything in Crowdin so far.
However, this changes a few `\u003` to `<` (pretty sure that was an artefact of
how we manually generated the json files in #3649), and it removes all the
translations that are identical to the English version, which I guess is a good
thing (but doesn't make a difference in practice).
I was looking for empty strings in en.json, that's how I found this one. It
resulted in an empty log entry when adding a co-author to an existing commit.
Fix two problems with running `go generate ./...` on Windows:
- the command would error out with `panic: Default config starting
comment not found` (depending on the setup of the local git client)
- after running the command, all files would show up as modified in git,
but without a diff. Staging the files would make them disappear again,
except for those that actually had changes.
Fix both of these by configuring git to check out the generated text
files with Unix line endings.
On Windows, trying to use lazygit with a language other than English
would result in the error message `open translations\ja.json: file does
not exist`.
The default shortcut to open git difftool (`ctrl+t`) is not available on
the "Local Branches" window. It is available when selecting a commit
from a local branch, a remote branch, or a tag from the "Local Branches"
window.
This is inconsistent since branches or tags are also commits, the
shortcut should also work on them directly.
This commit remedies this inconsistency by allowing the use of the
shortcut directly on a branch or a tag. The shortcut works both in the
"standard" mode and the "diffing" mode.
This reverts commit 3af545daf7, reversing
changes made to 629b7ba1b8.
We changed our mind about this and want to provide different options for
achieving the same thing, but with more flexibility.
- **PR Description**
The highlight is normally turned off in HandleFocusLost, but that's not
called when using ReplaceContext (and changing this would be a lot of
work, it seems), so turn it off manually for now.
For a moment I considered whether we want to show the new inactive
highlight when switching from suggestions to the prompt (actually this
did happen on master), but I decided against it for several reasons:
- it's not quite the right concept (the suggestions view is not the
"parent" context of the prompt),
- there's no benefit from seeing one of the suggestions selected (and
the selection would change arbitrarily when changing the filter string)
- there would be visual problems when the suggestions become empty, in
which case we would still highlight the first empty row (which you can
only see if you set the gui.theme.inactiveViewSelectedLineBgColor config
to some color). Now this could be considered a bug in the focus
management of the suggestions panel, but it doesn't seem worth fixing
this; the problem goes away by turning off the highlight.
The highlight is normally turned off in HandleFocusLost, but that's not called
when using ReplaceContext (and changing this would be a lot of work, it seems),
so turn it off manually here for now.
- **PR Description**
A filtered view would show stale data when the model changes but the
view is inactive. I think this could only happen when changing some git
state outside of lazygit; for example, when creating a new branch while
the branches panel has a filter set, but doesn't have the focus. (See
the added test for an example.)
Probably not the most import feature in the world, but when resizing the
terminal window while multiple popup panels were open at the same time, we would
only resize the topmost one.
The main reason for changing this is because it makes the next commit easier to
implement.
This is how we do it for confirmation with suggestions too, so be consistent. It
will make things easier later in this branch if we only have one context per
"panel" on the stack, even if the panel consists of two views.
Concretely this means:
- only push the message context onto the stack when opening the panel (this
requires making the description view visible manually; we do the same for
suggestions)
- when switching between message and description, use ReplaceContext rather than
PushContext
We forgot to handle the "suggestions" and "commitDescription" view names.
Instead of listing all the names of views that can appear in popups though,
let's use the context kind for this, which feels more robust.
This is a change in behavior: previously, clicking outside of the search or
filter prompt would close the prompt, now it no longer does (because search has
a persistent popup kind, but it wasn't listed in the list of view names before).
We will have to do this regularly in order to upload it to Crowdin (or Weblate
or whatever translation system we are going to use).
Unlike the non-English JSON files, the en.json file is not committed to the git
repo.
We write a hacky, one-off script to do that. We need this script only once, so
we don't bother polishing it much. We'll re-purpose it later in the branch to
convert the English translation set to JSON; that is an operation that we need
to do regularly in the future.
Reproduction recipe:
1. stage all changes in a file by pressing space on it in the files panel
2. enter the staged changes panel by pressing enter
3. unstage one of the changes
This makes the unstaged changes panel visible, but keeps the focus in
the staged changes panel. However, the highlight in the unstaged changes
view becomes visible, as if it were focused.
Fixes#3664
An inactive selection is one where the view is part of the context stack, but
not the active view. For example, the files view when you enter the staging
panel, or any view when you open a panel.
Remove the old mechanism of clearing the highlight in Layout.
This fixes a problem with a wrong highlight showing up in the staging panel when
entering a file with only staged changes.
Reproduction recipe:
1. stage all changes in a file by pressing space on it in the files panel
2. enter the staged changes panel by pressing enter
3. unstage one of the changes
This makes the unstaged changes panel visible, but keeps the focus in the staged
changes panel. However, the highlight in the unstaged changes view becomes
visible, as if it were focused.
To explain why this happens, you need to know how the selection highlighting of
a view is turned on or off. It is turned on when it gains the focus, i.e. when
ActivateFocus is called on it, which in turn happens when PushContext is called.
It is turned off in Layout when gocui sees that the current view is no longer
the same as last time, in which case it calls onViewFocusLost on the previous
current view.
This mechanism only works reliably when there is at most one PushContext call
per event handler. If there is more than one, then the first one gets its
highlight turned on, then the second one, but since gocui has never seen the
first one as the active view in Layout, it doesn't get the highlight turned off
again even though it should.
And this happens in the above scenario. When pressing enter on a file with only
staged changes, we first push the staging context (in
FilesController.EnterFile), and then later we push the stagingSecondary context
when we realize we only have staged changes. This leaves the highlight of the
staging context on.
- **PR Description**
Fix a performance regression that I introduced with v0.41: when entering
or leaving staging mode for a file, or when switching from a file that
has only unstaged changes to one that has both staged and unstaged
changes, there was a noticeable lag of about 500ms on my machine. With
the improvements in this PR we get this back down to about 20ms.
runewidth.StringWidth is an expensive call, even if the input string is pure
ASCII. Improve this by providing a wrapper that short-circuits the call to len
if the input is ASCII.
Benchmark results show that for non-ASCII strings it makes no noticable
difference, but for ASCII strings it provides a more than 200x speedup.
BenchmarkStringWidthAsciiOriginal-10 718135 1637 ns/op
BenchmarkStringWidthAsciiOptimized-10 159197538 7.545 ns/op
BenchmarkStringWidthNonAsciiOriginal-10 486290 2391 ns/op
BenchmarkStringWidthNonAsciiOptimized-10 502286 2383 ns/op
In d5b4f7bb3e and 58a83b0862 we introduced a combined mechanism for rerendering
views when either their width changes (needed for the branches view which
truncates long branch names), or the screen mode (needed for those views that
display more information in half or full screen mode, e.g. the commits view).
This was a bad idea, because it unnecessarily rerenders too many views when just
their width changes, which causes a noticable lag. This is a problem, for
example, when selecting a file in the files panel that has only unstaged
changes, and then going to one that has both staged and unstaged changes; this
splits the main view, causing the side panels to become a bit narrower, and
rerendering all those views took almost 500ms on my machine. Another similar
example is entering or leaving staging mode.
Fix this by being more specific about which views need rerendering under what
conditions; this improves the time it takes to rerender in the above scenarios
from 450-500s down to about 20ms.
This reintroduces the code that was removed in 58a83b0862, but in a slightly
different way.
The rendering of remote branches is in no way dependent on the width of the view
(or the screen mode). Unlike in the local branches view, we don't truncate long
branch names here (because there's no more information after them).
This is an error introduced in d5b4f7bb3e.
- **PR Description**
Some of our menus let you pick a value for some option (e.g. the sort
order menus for branches and commits). It's nice to see which one is the
current value when opening such a menu, so this PR implements that.
For menus that also have key bindings, the radio button goes between the
key and the label.
As an alternative, I considered selecting the current value when the
menu is opened; however, we currently have no menus where we select a
different entry than the first one, and it might be confusing for people
who are used to opening a menu and then pressing down-arrow a certain
number of times to get to a particular value.
- **Please check if the PR fulfills these requirements**
* [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] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [ ] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [ ] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
For checkboxes it probably doesn't really make sense to use them yet, because
we'd have to find a way how you can toggle them without closing the dialog; but
we already provide rendering for them to lay the ground.
But radio buttons can be used already, because for those it is ok to close the
dialog when choosing a different option (as long as there is only one grounp of
radio buttons in the panel, that is).
Always show the "Discard unchanged changes" menu item in the Discard
menu, just strike it through if not applicable. This will hopefully help
with confusion about the meaning of "all" in the "Discard all changes"
entry; some people misunderstand this to mean all changes in the working
copy. Seeing the "Discard unstaged changes" item next to it hopefully
makes it clearer that "all" is meant in contrast to that.
Strike it through if not applicable. This will hopefully help with confusion
about the meaning of "all" in the "Discard all changes" entry; some people
misunderstand this to mean all changes in the working copy. Seeing the "Discard
unstaged changes" item next to it hopefully makes it clearer that "all" is meant
in contrast to that.
- **PR Description**
Several custom patch commands on parts of an added file would fail with the
confusing error message "error: new file XXX depends on old contents".
These were dropping the custom patch from the original commit, moving the
patch to a new commit, moving it to a later commit, or moving it to the index.
We fix this by converting the patch header from an added file to a diff against
an empty file. We do this not just for the purpose of applying the patch, but
also for rendering it and copying it to the clip board. I'm not sure it matters
much in these cases, but it does feel more correct for a filtered patch to be
presented this way.
Fixes#3679.
- **Please check if the PR fulfills these requirements**
* [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] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [ ] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [ ] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
Several custom patch commands on parts of an added file would fail with the
confusing error message "error: new file XXX depends on old contents". These
were dropping the custom patch from the original commit, moving the patch to a
new commit, moving it to a later commit, or moving it to the index.
We fix this by converting the patch header from an added file to a diff against
an empty file. We do this not just for the purpose of applying the patch, but
also for rendering it and copying it to the clip board. I'm not sure it matters
much in these cases, but it does feel more correct for a filtered patch to be
presented this way.
We're going to add another argument in the next commit, and that's getting a bit
much, especially when most of the arguments are bool and you only see true and
false at the call sites without knowing what they mean.
This currently works (albeit with a bit of manual work, as the user needs to
resolve conflicts), and we add this test just to make sure that we don't break
it with the following change.
This currently works, we add it as a regression test to make sure we don't break
it. It is an interesting test because it turns the deletion of the file in the
moved-from commit into a modification.
- **PR Description**
This fixes two layout problems with pagers that draw a horizontal line
across the entire width of the view (e.g. delta):
- sometimes the width of that line was one character too long or too
short in the staged changes view
- when changing from a file or directory that has only staged or only
unstaged changes to one that has both, the length of the horizontal line
was totally off and only redraw correctly at the next refresh
This is important when using a pager that draws a horizontal line across the
entire width of the view; when changing from a file or directory that has only
unstaged (or only staged) changes to one that has both, the main view is split
in half, but the PTY task would be run on the view in its old state, so the
horizonal line would be too long and wrap around.
All PTYs were created with the size of the main view, on the assumption that
main and secondary always have the same size. That's not true though; in
horizontal split mode, the width of the two views can differ by one because of
rounding, and when using a pager that draws a horizontal line across the width
of the view, this is visible and looks very ugly.
- **PR Description**
As a followup to [this
discussion](https://github.com/jesseduffield/lazygit/pull/3388#issuecomment-2002308045),
this PR adds a way to add a prompt text to menus. It is shown above the
menu items, separated by a blank line. We use it to add a prompt to the
remote branch checkout menu.
Stefan Haller