Assert the entire lines using Equals instead of Contains. This makes the tests a
bit easier to read, and it makes it much easier to decide how they need to be
changed when we change the layout (like we do in the last commit of this
branch).
It is true that this requires changing all these tests for any future UI
changes, but I think this is a good price to pay; those adaptions are trivial
and can be done without thinking.
I'm pretty sure that the check for the main view was meant to be done with the
commit selected in the commits panel, not with the first file of the commit
files view selected, so it was pressing enter too early. It's pure coincidence
that the test worked.
- **PR Description**
Some people have the need to get at the file content of a file as it was
in an earlier commit. They expect to press `e` in the commit files view
and get the file opened in the state it was in at that commit, somehow.
I explained a few times (e.g. in #3902, #4109, and #4327) that this is
not how `e` should work; so if we want this as a feature, we'd need it
as a separate command. However, it's a bit tricky to implement; if we
check out the selected file to a temp file, it's unclear when to remove
the file again. Alternatively we could use EditAndWait to open the file,
then we would block until the user closes the editor and delete the file
then. This is probably not the best user experience though, e.g. it
wouldn't allow opening two files from an older commit at once.
Instead of finding solutions to all these questions, this PR takes a
simpler route and adds a command to the "Copy to Clipboard" menu that
allows copying the entire content of a file. Users can then open a new,
empty editor buffer and paste it in, this is almost as good as opening a
temp file, but without all the questions. This was suggested in #4327.
- **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)
* [x] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [ ] If a new UserConfig entry was added, make sure it can be
hot-reloaded (see
[here](https://github.com/jesseduffield/lazygit/blob/master/docs/dev/Codebase_Guide.md#using-userconfig))
* [ ] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
This is useful for copying the entire content of the selected file as it was at
the selected commit.
We only add it to the commit files panel; it is not needed in the files panel,
because there you can simply press "e" to edit the file.
- **PR Description**
This allows changing git config values while lazygit is running (e.g. in a
different terminal tab, or even in lazygit's ":" shell prompt), and have them
take effect immediately, while still getting some benefit from caching them
while lazygit is in the foreground.
Addresses #4240.
This allows changing git config values while lazygit is running (e.g. in a
different terminal tab, or even in lazygit's ":" shell prompt), and have them
take effect immediately, while still getting some benefit from caching them
while lazygit is in the foreground.
@jesseduffield:
> Let's revert this PR, given that, as @TimShilov says, the
post-checkout hook will receive a flag stating whether the checkout was
for a file or a branch, meaning it's within the user's power to just
update the hook script to only run on branch checkouts if desired.
Before we changed the commitPrefix config to a list in #4261, we had
this bug where the defaults section in `Config.md` would erroneously
list the default for commitPrefix as
```yml
git:
commitPrefix:
pattern: ""
replace: ""
```
This was not correct, commitPrefix was a pointer, and the default for
that was nil, which is not the same.
Now, some people copied and pasted the entire defaults section into
their config files, setting the commitPrefix to an empty pattern (which
is not the same as not setting it at all). And this caused the branch
name to be filled in to the subject field for every commit; see for
example https://github.com/jesseduffield/lazygit/discussions/3632.
New users copying the defaults section into their config file in the
current version no longer have this problem because now that
commitPrefix is a list, it is no longer included in the defaults
section. However, the migration that we added in #4261 would happily
carry over those empty strings into a list entry, so people migrating
from an older version still have the broken config in their config
files.
To work around the issue, ignore commit prefix settings whose pattern is
an empty string. I can't imagine a valid reason why people would
actually want to set the pattern to an empty string, so I assume this
only comes from the broken defaults problem described above.
I'm not mentioning *why* it's not a good idea, and I'm not sure it's important
to explain this to users. I'll say it here:
- it exposes users to potential bugs like the one described in the previous
commit
- if we decide to change the default of an option to something "better" (like we
did with the "show graph" setting), users don't benefit from what we think is
an improvement for most users
Before we changed the commitPrefix config to a list in #4261, we had this bug
where the defaults section in Config.md would erroneously list the default for
commitPrefix as
git:
commitPrefix:
pattern: ""
replace: ""
This was not correct, commitPrefix was a pointer, and the default for that was
nil, which is not the same.
Now, some people copied and pasted the entire defaults section into their config
files, setting the commitPrefix to an empty pattern (which is not the same as
not setting it at all). And this caused the branch name to be filled in to the
subject field for every commit; see for example
https://github.com/jesseduffield/lazygit/discussions/3632.
New users copying the defaults section into their config file in the current
version no longer have this problem because now that commitPrefix is a list, it
is no longer included in the defaults section. However, the migration that we
added in #4261 would happily carry over those empty strings into a list entry,
so people migrating from an older version still have the broken config in their
config files.
To work around the issue, ignore commit prefix settings whose pattern is an
empty string. I can't imagine a valid reason why people would actually want to
set the pattern to an empty string, so I assume this only comes from the broken
defaults problem described above.
Some operating systems 'open' implementations do not like
when some special characters are unencoded, so they will
double-enconde the branch name, which we already encode.
This particularly matters since branch names with / are common
There's no way to tell cron to run a job on the first Saturday of a
month, so we tell it to run every Saturday, and manually check whether
it's the first week of the month. This is not ideal because we'll get
notifications about failed releases three times a month, but it's better
than nothing for now.
There's no way to tell cron to run a job on the first Saturday of a month, so we
tell it to run every Saturday, and manually check whether it's the first week of
the month. This is not ideal because we'll get notifications about failed
releases three times a month, but it's better than nothing for now.
- **PR Description**
When changing the language in the config file while lazygit is running,
the panel titles and tab titles weren't properly updated. I noticed this
while working on #4359.
Probably not an important feature for users, because they are unlikely
to change the language all the time; but it's still nice if this isn't
broken.
- **PR Description**
The width calculations didn't take multi-byte characters into account,
so the options bar was cut off too early for these.
Fixes#4353.
Rewording a commit at the beginning of a long branch can take very long;
without this change, the commit message panel would stay visible with a blinking
cursor during that time, which is very confusing.
This has the slight downside that it will say "Rebasing" in the lower right
corner until the operation is done; but we already have this problem when doing
custom patch operations, or dropping changes from a commit, so it's not new, and
we can think about how to fix all these another time.
WithGpgHandling already does an async refresh when done, so there's no need to
do one here for the case of amending the head commit. On top of that,
WithGpgHandling uses WithWaitingStatus and works in the background, so the
Refresh here would come too early anyway.
All this does is clear the preserved commit message; however, we open the commit
message panel with PreserveMessage: false when rewording, so this is not
necessary.
- **PR Description**
Fix a few things that started to crop up in my editor recently, probably
because of an updated gopls or something (I didn't investigate more
closely).
For some reason the //nolint:golint,unused comment no longer seems to work after
I updated gopls (I think).
But I also don't understand why we mark unused stuff with linter comments
instead of just getting rid of it.
- **PR Description**
I want to be able to configure custom commands that I don't need very
often; I don't want these to pollute the global keybindings menu, and I
don't want to assign globally unique keybindings to them (because there
are only so many of these available, and also because I wouldn't be able
to remember them, because the commands are not used often). However, I
still want to invoke them through keybindings somehow.
I find that the perfect solution for this is to configure a menu that
contains custom commands. I can pop open the menu using only one key
that I need to remember, but I can access the individual custom commands
inside using keys that don't need to be unique with the rest of the
global keybindings.
In this PR we achieve this by adding an optional `subCommands` property
to customCommand that can be used instead of the other properties like
`command`, etc. This is an alternative approach to #4276, which added a
new top-level property for custom command menus.
Potentially closes#3799.
- **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)
* [x] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [x] If a new UserConfig entry was added, make sure it can be
hot-reloaded (see
[here](https://github.com/jesseduffield/lazygit/blob/master/docs/dev/Codebase_Guide.md#using-userconfig))
* [x] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
