The output from background fetching is noisy and pollutes the command
log. Don't show it by default, unless there were errors, in which case
it is important to see e.g. which fork was deleted.
However, show it when there was an error. This is important for the case that a
fork that you have as a remote was deleted, in which case the command log is the
only way to get notified about that.
Most of our prompts don't (shouldn't) allow empty input, but most
callers didn't check, and would run into cryptic errors when the user
pressed enter at an empty prompt (e.g. when creating a new branch). Now
we simply don't allow hitting enter in this case, and show an error
toast instead.
This behavior is opt-out, because there are a few cases where empty
input is supported (e.g. creating a stash).
This doesn't really solve a pressing problem, because I guess it's unlikely that
users add spaces at the beginning or end of what they type into a prompt; but it
could happen, and in this case we almost always want to strip it. Just adding
this here for completeness while I was working on this code.
The only exception is the input prompt of custom commands, because who knows
what users want to use that input for in their custom command.
Most of our prompts don't (shouldn't) allow empty input, but most callers didn't
check, and would run into cryptic errors when the user pressed enter at an empty
prompt (e.g. when creating a new branch). Now we simply don't allow hitting
enter in this case, and show an error toast instead.
This behavior is opt-out, because there are a few cases where empty input is
supported (e.g. creating a stash).
Previously it was used both for the Confirm handler and the Cancel handler, as
well as for the Confirm handler of confirmation popups (not prompts). There was
no other way to do it given how wrappedConfirmationFunction was shared between
all these; but now there is. The logic is really only needed for the Confirm
handler of prompts.
This doesn't fix anything, it just makes things clearer.
And call this new helper function from both wrappedConfirmationFunction and
wrappedPromptConfirmationFunction; this gives us more flexibility to do
different things in each of those.
Introduce the 'SelectedSubmodule' struct and allow using it as a
placeholder value.
Add a corresponding test.
Update the documentation to include it among the listed placeholder
values.
Some of our documentation is auto-generated from the source code (the
defaults section in Config.md, and the keybinding cheat sheets), and so
is the JSON schema for the config file. We have a check running on CI
that verifies that when the source code changes (e.g. a new config
option is added), those files are properly regenerated, to make sure
they are always up to date with the latest version of the source code.
This causes a problem when people look at the documentation for a newly
added config option and wonder why it doesn't work in the lazygit
version they are using. Lots of issues were filed where people report
this as a bug, and we have to patiently explain to them that the
documentation describes a feature that hasn't been released yet. A
similar problem occurs when we rename a config option (as has recently
happened with the 'paging' config, which was renamed to 'pagers' in
#4953), in which case the user's editor (if it supports JSON validation
against the jsonschema store) starts to complain about the old config,
even though it still works, and the new one doesn't yet.
To solve this, keep the documentation and the JSON schema unchanged for
the lifetime of a release; make those continuous changes in a separate
copy of those folders, and only copy the files back to the real location
right before we make a release. To facilitate this, we add a script to
conveniently create a PR for copying the files back, and add a check to
the release workflow to abort with an error if this was forgotten.
Note that we only use this approach in order to solve the problem with
the auto-generated files; this has a consequence for making changes to
the other, non-auto-generated parts of the docs. For example, when
fixing a spelling error, rewording a paragraph to explain it better, or
adding an entirely new file, those changes will now have to be made in
docs-master, which means:
1. if we forget this and make the change in `docs` accidentally, it will
be reverted with the next release.
2. if we do remember to make the change in docs-master, it will take
until the next release for it to be visible to users.
We can mitigate 2. by making the identical change in both places, but I
think we should first wait and see how often it happens, and whether it
is actually a problem.
This needs to be run immediately before creating a release.
We could go further here and use gh to create the PR, but since I'm usually
logged in with my work account to gh, this won't help me. The git push command
prints the URL to create the PR, so it's a simple matter of command-clicking it,
which is good enough for me.
The plan is to keep the original docs and schema folders unchanged for the
duration of a release; we'll only continuously update the -master copies. Right
before a new release we will copy them over.
When pressing '.' (next page) or ',' (previous page), the selection now
stays at the bottom or top of the viewport respectively, instead of
being centered which caused items to scroll off. (If the selection is
not already on the last/first line of the view, '.'/',' moves it there
without scrolling.)
This implements a special case for page navigation as suggested by the
maintainer in issue #5017, keeping the cursor position consistent with
user expectations for page-based navigation.
Fixes#5017
When pressing '.' (next page) or ',' (previous page), the selection
now stays at the bottom or top of the viewport respectively, instead
of being centered which caused items to scroll off. If the selection is not
already on the last/first line of the view, '.'/',' moves it there without
scrolling.
This implements a special case for page navigation as suggested by
the maintainer in issue #5017, keeping the cursor position consistent
with user expectations for page-based navigation.
Fixes#5017
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
### PR Description
This allows for having extra slashes in git URLs. Especially in
submodules. Those may be used to avoid warnings with older bitbake
fetcher implementations in yocto. Which warns about relative urls when
not having a slash in git urls.
- git@bitbucket.org:project/repo.git -> generates a warning in bitbake,
which is annoying.
- git@bitbucket.org:/project/repo.git -> does not generate a warning in
bitbake.
But when trying to open a PR from lazygit with an url like
git@bitbucket.org:/project/repo.git leads to
https://bitbucket.org//project/repo being opened and one has to stare at
a blank page unless one removes the extra / manualy.
This PR updates the regex used for matching git url fragments in a way,
that the extra `/` is ignored.
This allows for having extra slashes in git urls, for example to avoid
warnings with older bitbake fetcher implementations in yocto. Which
warns about a missing / in git urls
The "Cycle pagers" command wasn't rendered correctly, because it's bound
to '|' by default, but this was taked as a table column delimiter. Fix
this by escaping the pipe character.
A similar thing could happen for the description or tooltip (and did in
fact, for a tooltip in the russion translation), so escape those too
just to be sure.
The "Cycle pagers" command wasn't rendered correctly, because it's bound to '|'
by default, but this was taked as a table column delimiter. Fix this by escaping
the pipe character.
A similar thing could happen for the description or tooltip (and did in fact,
for a tooltip in the russion translation), so escape those too just to be sure.
### PR Description
The existing diff parser incorrectly treated subsequent lines beginning
with `---` as filename headers while processing hunks. This caused
corruption when dashed lines appeared within diffs themselves.
Restrict filename detection to only occur between hunks.
This repository https://github.com/abobov/lazygit-fixup-issue
demonstrates the issue:
- clone repository
- run `git reset --soft HEAD~`
- try `<c-f>` Find base commit for fixup
- `fatal: no such path ...` error
The existing diff parser incorrectly treated subsequent lines beginning
with "---" as filename headers while processing hunks. This caused
corruption when dashed lines appeared within diffs themselves.
Restrict filename detection to only occur between hunks.
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.
