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
- **PR Description**
In the solving of #4194 we had some discussion about the repeated
marshalling and unmarshalling of the content in our migrations.
https://github.com/jesseduffield/lazygit/issues/4194#issuecomment-2661375136.
I was feeling the itch to see if there was a meaningful performance
impact to that, and this is the results! I added a benchmark first that
uses the entirety of `Config.md`. This ensures a worst-case scenario for
the repeated parsing, and probably at least 1 user has done this for
their config. Here were the benchmark results prior and after this PR:
## Before
```
$ go test ./pkg/config/ -bench=. -benchmem -count=10
goos: linux
goarch: amd64
pkg: github.com/jesseduffield/lazygit/pkg/config
cpu: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz
BenchmarkMigrationOnLargeConfiguration-8 85 18165916 ns/op 1501442 B/op 19316 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 50 21024442 ns/op 1501473 B/op 19316 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 75 18814769 ns/op 1501509 B/op 19316 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 60 17886812 ns/op 1501434 B/op 19316 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 97 17767498 ns/op 1501448 B/op 19316 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 62 18749923 ns/op 1501478 B/op 19316 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 62 19248265 ns/op 1501467 B/op 19316 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 92 14771199 ns/op 1501423 B/op 19316 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 67 16345152 ns/op 1501440 B/op 19316 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 98 16785737 ns/op 1501472 B/op 19316 allocs/op
PASS
ok github.com/jesseduffield/lazygit/pkg/config 14.474s
```
so somewhere in the range of 14 to 21 ms added to startup time.
## After
```
$ go test ./pkg/config/ -bench=. -benchmem -count=10
goos: linux
goarch: amd64
pkg: github.com/jesseduffield/lazygit/pkg/config
cpu: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz
BenchmarkMigrationOnLargeConfiguration-8 440 2936145 ns/op 265800 B/op 3928 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 428 3099183 ns/op 265787 B/op 3928 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 355 3074069 ns/op 265785 B/op 3928 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 478 3031144 ns/op 265792 B/op 3928 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 375 2795470 ns/op 265785 B/op 3928 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 406 2688491 ns/op 265791 B/op 3928 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 375 3092990 ns/op 265791 B/op 3928 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 379 2789022 ns/op 265785 B/op 3928 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 417 3108530 ns/op 265785 B/op 3928 allocs/op
BenchmarkMigrationOnLargeConfiguration-8 487 2848502 ns/op 265788 B/op 3928 allocs/op
PASS
ok github.com/jesseduffield/lazygit/pkg/config 15.352s
```
So somewhere between 2.6 and 3.1 ms.
Is that a meaningful speedup? I'm not sure, but it's something! I had to
add the bit of complexity mentioned in the comment to track whether we
had made any changes, but that doesn't feel fundamentally much more
complex to me, since we were already implicitly tracking that fact with
whether the string file changed.
- **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))
* [ ] 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))
* [ ] 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
- **PR Description**
Filter out [dev] comments earlier. Previously we only filtered them out
from the example config section in Config.md, but they still appeared in
the schema. This is not ideal, because the schema descriptions can
appear in editors on mouse hover or in auto-completions. So filter them
out earlier, so that they don't appear in the schema either.
Previously we only filtered them out from the example config section in
Config.md, but they still appeared in the schema. This is not ideal, because the
schema descriptions can appear in editors on mouse hover or in auto-completions.
So filter them out earlier, so that they don't appear in the schema either.
- **PR Description**
Some people have post-checkout hooks that take a lot of time, which
makes discarding changes slow. You can argue that a post-checkout hook
should only run when you switch branches, so it doesnt't have to run
when checking out single files or directories. You can also argue that
lazygit might have implemented discarding changes by taking the current
patch and applying it in reverse, which wouldn't have run a
post-checkout hook either.
So disable them for all cases where we use git checkout with a path;
this includes checking out a file from the commit files view.
Fixes#4272.
Some people have post-checkout hooks that take a lot of time, which makes
discarding changes slow. You can argue that a post-checkout hook should only run
when you switch branches, so it doesnt't have to run when checking out single
files or directories. You can also argue that lazygit might have implemented
discarding changes by taking the current patch and applying it in reverse, which
wouldn't have run a post-checkout hook either.
So disable them for all cases where we use git checkout with a path; this
includes checking out a file from the commit files view.
