| Age | Commit message (Collapse) | Author |
|---|
|
|
|
We'll use it with a more general meaning later in this branch.
|
|
- **PR Description**
Add a user config `gui.expandedSidePanelWeight` which lets you change
the default weight of 2 that gets assigned to the expanded side panel if
`expandFocusedSidePanel` is true.
Closes #3621.
- **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))
* [x] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
|
|
|
|
|
|
- **PR Description**
This fixes three different problems; two were recent regressions, one
has never worked.
1. For branches whose remote is not stored locally, don't ask to force
push right away. Try a normal push first. This broke with #3528.
2. For branches whose remote is not stored locally (but only for those),
if the server rejects the update, ask to force push. This broke with
#3387.
3. When force-pushing a branch whose remote is not stored locally, use
`--force` instead of `--force-with-lease`; otherwise the push would
always fail with a "stale info" error. This has never worked.
Fixes #3588.
|
|
The test needs all three fixes from this branch to succeed.
|
|
--force-with-lease simply doesn't work in this case, it will always return a
"stale info" error.
|
|
This describes better what it is, and we're going to add the regular --force in
the next commit.
No change in behavior in this commit.
|
|
This broke with 81b497d186 (#3387). In that PR I claimed that we never want to
ask for force-pushing if the server rejected the update, on the assumption that
this can only happen because the remote tracking branch is not up to date, and
users should just fetch in this case. However, I didn't realize it's even
possible to have a branch whose upstream branch is not stored locally; in this
case we can't tell ahead of time whether a force push is going to be necessary,
so we _have_ to rely on the server response to find out. But we only want to do
that in this specific case, so this is not quite an exact revert of 81b497d186.
|
|
This broke with #3528.
If the remote branch is not stored locally, we only see question marks in the
branch status. In this case we can't tell whether we need to force-push, so it's
best to assume that we don't, and see if the server rejects the push, and react
to that by asking to force push. This second part is also broken right now,
we'll fix this in the next commit.
|
|
- **PR Description**
All boolean config keys were missing from the generated Config.md.
- **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))
* [x] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
|
|
The reason why they didn't appear is that they didn't get a default value in the
generated schema; this commit fixes that.
|
|
Lazygit doesn't touch this, the comment is just not true.
I wonder if we need the config at all, actually; I'd be in favor of removing it.
|
|
- **PR Description**
When branches are sorted by recency we have this logic that first loads the
branches so that they can be rendered quickly; in parallel, it starts loading
the reflog in the background, and when that's done, it loads the branches again
so that they get their recency values. This means that branches are loaded twice
at startup.
We don't need this logic when branches are not sorted by recency, so we can
simply load branches and reflog in parallel like everything else.
This shouldn't change any user observable behavior, it just avoids doing
unnecessary work at startup.
|
|
When branches are sorted by recency we have this logic that first loads the
branches so that they can be rendered quickly; in parallel, it starts loading
the reflog in the background, and when that's done, it loads the branches again
so that they get their recency values. This means that branches are loaded twice
at startup.
We don't need this logic when branches are not sorted by recency, so we can
simply load branches and reflog in parallel like everything else.
This shouldn't change any user observable behavior, it just avoids doing
unnecessary work at startup.
|
|
The behavior described in the comment is no longer what we do, it was changed in
ae66f720f5; we now always reuse the state.
|
|
Pin golangci version to 1.58.
It is annoying when CI builds suddenly start to fail because the linter
was updated and finds new things to complain about.
Updating the linter and fixing the code accordingly should be a
dedicated activity.
|
|
It is annoying when CI builds suddenly start to fail because the linter was
updated and finds new things to complain about.
Updating the linter and fixing the code accordingly should be a dedicated
activity.
|
|
### PR Description
- Fix calculation of tooltip height; for tooltips that are just one or
two characters longer than the available width, the last word would be
cut off. On my screen this happened for the tooltip for the fixup
command.
- Fix tooltip of fixup command.
Fixes #3600.
|
|
|
|
For tooltips that are just one or two characters longer than the available
width, the last word would be cut off. On my screen this happened for the
tooltip for the fixup command.
|
|
|
|
`.golangci.yml` (#3596)
## Context:
https://github.com/jesseduffield/lazygit/pull/3592#issuecomment-2129535231
|
|
`.golangci.yml`
|
|
I feel this is necessary when I worked on
https://github.com/jesseduffield/lazygit/pull/3592.
|
|
|
|
Resolves #3573
It looks like the update to go1.22 is done by
https://github.com/jesseduffield/lazygit/pull/3574. So it should be OK
to close #3573 when this PR is merged.
## PR Description
Add [`copyloopvar`](https://github.com/karamaru-alpha/copyloopvar) to
enabled linters to detect unnecessary assignments in `for` loops.
## Context
@jesseduffield and I were talking about necessity of this linter here.
https://github.com/jesseduffield/lazygit/issues/3573#issuecomment-2123732829
|
|
|
|
- **PR Description**
Add property `outputTitle` to CustomCommand. It can optionally be used
to set the title of the panel that shows the output of a command (when
`showOutput` is true). If left unset, the command string is used as the
title.
Closes #3576.
|
|
It can optionally be used to set the title of the panel that shows the output of
a command (when showOutput is true). If left unset, the command string is used
as the title.
|
|
- **PR Description**
This PR forces lazygit to focus to the `Commits` view after moving a
custom (partial) patch in a new commit.
This closes #3200.
|
|
|
|
It used to be a common thing to have to update `Config.md` in a PR (and
we often forgot despite the template). As of #3565 this is no longer
necessary, so remove this from the template.
Updating docs in general is still a good thing to think about, so we
leave this in.
|
|
It used to be a common thing to have to update Config.md in a PR (and we often
forgot despite the template). As of #3565 this is no longer necessary, so remove
this from the template.
Updating docs in general is still a good thing to think about, so we leave this
in.
|
|
Updated the company sponsors with the new name of my company
|
|
- **PR Description**
This uses the JSON schema generated in
https://github.com/jesseduffield/lazygit/pull/3039 to generate and
replace the default lazygit config in Config.md when running `go
generate ./...`
Relevant issue: https://github.com/jesseduffield/lazygit/issues/3441
The generated config contains all the entries that have default values
set in `user_config.go`
|
|
This makes the generated default config in Config.md match the original
order.
|
|
|
|
|
|
|
|
- **PR Description**
Some people push to a different branch (or even remote) than they pull
from. One example is described in #3437. Our logic of when to request a
force push is not appropriate for these workflows: we check the
configured upstream branch for divergence, but that's the one you pull
from. We should instead check the push-to branch for divergence.
Fixes #3437.
|
|
To determine whether we need to ask for force pushing, we need to query the push
branch rather than the upstream branch, in case they are not the same.
|
|
In a triangular workflow the branch that you're pulling from is not the same as
the one that you are pushing to. For example, some people find it useful to set
the upstream branch to origin/master so that pulling effectively rebases onto
master, and set the push.default git config to "current" so that "feature"
pushes to origin/feature.
Another example is a fork-based workflow where "feature" has upstream set to
upstream/main, and the repo has remote.pushDefault set to "origin", so pushing
on "feature" pushes to origin/feature.
This commit adds new fields to models.Branch that store the ahead/behind
information against the push branch; for the "normal" workflow where you pull
and push from/to the upstream branch, AheadForPush/BehindForPush will be the
same as AheadForPull/BehindForPull.
|
|
In preparation for adding AheadForPush/BehindForPush in the next commit.
|
|
Our code doesn't realize that we need to prompt the user to force push, when the
branch is up-to-date with its upstream but not with the branch that we're
pushing to.
|
|
It is unexpected that a function called PushBranch also sets the upstream
branch; also, we want to add a PushBranch function in the next commit that
doesn't.
|
|
This guards against accidentally renaming a model field and thereby breaking
user's custom commands. With this change we'll get a build failure when we do
that.
|
|
- **PR Description**
Bumps go from 1.21 to 1.22, and removes newly redundant loop variable
re-declarations now that in 1.22 the variables are automatically
redeclared in each iteration for us.
- **Please check if the PR fulfills these requirements**
* [ ] Cheatsheets are up-to-date (run `go generate ./...`)
* [ ] 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))
* [ ] Docs (specifically `docs/Config.md`) have been updated if
necessary
* [ ] You've read through your own file changes for silly mistakes etc
<!--
Be sure to name your PR with an imperative e.g. 'Add worktrees view'
see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for
examples
-->
|
|
In go 1.22, loop variables are redeclared with each iteration of the
loop, rather than simple updated on each iteration. This means that we
no longer need to manually redeclare variables when they're closed over
by a function.
|
