- **PR Description**
The default binding for ConfirmInEditor is <a-enter>, which has two
problems:
- some terminal emulators don't support it, including the default
terminal on Mac (Terminal.app)
- on Windows it is bound to toggling full-screen
Ideally we would use `<c-enter>` instead (and Command-Enter on Mac), but
neither is possible without https://github.com/gdamore/tcell/issues/671,
so for the time being add an alternate keybinding which works
everywhere.
Show both bindings in the footer of the commit description panel if they
are both non-null. While we're at it, fix the footer for the case where
either or both of the keybindings are set to `<disabled>`.
And finally, change "commit" to "submit" in that footer; we use the same
panel also for creating tags, in which case "commit" is not quite right.
The default binding for ConfirmInEditor is <a-enter>, which has two problems:
- some terminal emulators don't support it, including the default terminal on
Mac (Terminal.app)
- on Windows it is bound to toggling full-screen
Ideally we would use <c-enter> instead (and Command-Enter on Mac), but neither
is possible without https://github.com/gdamore/tcell/issues/671, so for the time
being add an alternate keybinding which works everywhere.
Show both bindings in the footer of the commit description panel if they are
both non-null. While we're at it, fix the footer for the case where either or
both of the keybindings are set to <disabled>.
And finally, change "commit" to "submit" in that footer; we use the same panel
also for creating tags, in which case "commit" is not quite right.
- **PR Description**
In longer branches there's often the need to jump to the beginning of
the branch, e.g. in order to re-review all commits from the beginning.
There's no easy way to do this in lazygit.
In this PR I overload the "go to bottom" key (`>`) to jump to the first
commit of the current branch if the selection is above it, and only then
jump to the very bottom. I like that we don't need to introduce a new
key binding for this.
It's never called, the binding ListController.HandleGotoBottom wins.
The functionality of loading more commits is implemented by GetOnFocus, and this
way it works not only for '>', but also for other navigation keys like page
down.
BeginInteractiveRebaseForCommit is used for all the patch commands, and for
rewording. It works by setting the commit we want to stop at to 'edit'; this
doesn't work for merge commits. This wasn't a problem for the patch commands so
far, because you typically don't use custom patches with merge commits (although
we don't prevent this; maybe we should?).
However, it was a problem when you tried to reword a merge commit; this
previously failed with an error, as the test added in the previous commit
demonstrated.
Also, we want to add a new patch command that has to stop *before* the selected
commit (pull patch to new commit before the original one), and this wouldn't
work for the first commit in a feature branch, because it would have to set the
last commit before that to 'edit', which isn't possible if that's a merge (which
is likely).
To fix all this, use a 'break' before the selected commit if the commit is a
merge. It is important that we only do it in that case and not always, otherwise
we would break the new regression tests that were added a few commits ago.
I almost broke this during the development of this branch, so add a test to
guard against that. The point here is that the stack remains intact, i.e. the
newly created commit is the last commit of the lower branch, and thus shows the
"*".
I almost broke this during the development of this branch, so add a test to
guard against that. The point here is that the stack remains intact, i.e. the
renamed commit is the head of the lower branch, and thus shows the "*".
- **PR Description**
Fixes https://github.com/jesseduffield/lazygit/issues/3961
Their issue where the default `allBranchesLogCmd` default remains
present is because we just do a `lo.Uniq(lo.WithoutEmpty())` on the
combined list of `allBranchesLogCmd` and `allBranchesLogCmds`.
At the point of this code, it is not possible to tell whether the value
present in `allBranchesLogCmd` is user-provided or not. We have already
merged the config with the default config, so the user not setting
anything, and the user explicitly setting "Yes, I want the default", are
indistinguishable.
Based on that bug report, I'm assuming that users that have not set
anything for `allBranchesLogCmd`, but _have_ set something for
`allBranchesLogCmds`, just want the list they have specified in the
plural version. Some users have likely figured out they can explicitly
set `allBranchesLogCmd: ""` to get this behavior, but most would not.
To achieve this desired behavior, I figure it is easiest to just migrate
all user config to `allBranchesLogCmds`. If they have explicitly set a
non-empty value in `allBranchesLogCmd`, it will be pulled over. If they
set an empty string, it will be excluded.
- **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))
* [ ] 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**
The utils package is a bit of a heterogeneous bag of miscellaneous
things at different abstraction levels right now; ideally it should only
contain low-level utilities similar to the helpers in utils/slice.go.
Further cleanup is possible here, e.g. something like rebase_todo.go
shouldn't be in this utils package. This PR doesn't address that,
however.
The goal of this PR is just to make it possible to import utils from any
other package. Previously it wasn't possible to import it from config,
because some of the stuff in utils depended on the config package. So
here we move only those things to better places. See the individual
commit messages for details.
- **PR Description**
Previously, custom commands had a `stream` field that was overloaded
with two meanings: 1) it made the command's output appear in the log
view, and 2) it used a pty for running the command. It makes sense to be
able to configure these independently, so add a separate `pty` field
(although that's probably rarely needed in practice).
Also, the `stream` and `showOutput` fields were conflicting; they could
be used together, but when setting them both to true, the popup would
always show "empty output", so this doesn't make sense. Combine them
both into a single `output` property with the possible values "none",
"log", or "popup".
We still have some more redundancy here, for example pty is only used
when output is set to "log", and neither output nor pty are used when
subprocess is true. But I stopped there, because I think this is already
an improvement over the previous state.
- **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] 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
This decouples StreamOutput from whether a PTY is used. In most cases we just
want to see the output in the log window, but don't have to use a PTY, e.g. for
the bisect commands.
This has the implication that custom commands that are using "stream: true" no
longer use a PTY. In most cases that's probably a good thing, but we're going to
add a separate pty config for those who really wanted this.
- **PR Description**
As a followup to #2533, reduce the memory consumption some more by
optimizing the storage of the pipe sets used for the commit graph.
Some coarse measurements (taken by opening the respective repo, typing
`4 >`, and waiting for all commits to be loaded, and then reading the
Memory column in Activity Monitor):
| | master | this PR |
| ------------- | ------- | ------- |
| git | 2.5 GB | 1.0 GB |
| our work repo | 2.3 GB | 1.3 GB |
| linux kernel | 94.8 GB | 38.0 GB |
It's still not really usable for the linux kernel, but for all other
repos that I come across in my daily use of lazygit, it works quite well
now.
Hopefully, graphs will never get wider than 32768 characters. (They would get
kind of hard to navigate if they did...)
This reduces the size of the Pipe struct from 48 to 32 bytes, which makes a
significant difference when there are many millions of instances.
This saves some memory at the cost of a slight performance increase (I suppose
reallocting the slice when adding new Pipes is slightly more expensive now).
Performance of the BenchmarkRenderCommitGraph benchmark is 130μs before, 175μs
after. I'm guessing this is still acceptable.
Change the base type of some of our enums from int to uint8, and reorder fields
for better packing. This reduces the size of models.Commit from 152 to 132 bytes
on my machine.
This doesn't improve overall memory usage significantly, but why not save a
little bit of memory if it's easy.
We need to pass %P instead of %p in the format string of the git log command, so
that the parent hashes have the full length and can be shared with the real
hashes.
This in itself is not an improvement, because hashes are unique (they are shared
between real commits and rebase todos, but there are so few of those that it
doesn't matter). However, it becomes an improvement once we also store parent
hashes in the same pool; but the real motivation for this change is to also
reuse the hash pointers in Pipe objects later in the branch. This will be a big
win because in a merge-heavy git repo there are many more Pipe instances than
commits.
The "// merge commit" comment was plain wrong, this is any commit that has a
parent, merge or not. The "else if" condition was unnecessary, a plain "else"
would have been enough. But the code in the two blocks was almost identical, so
extract the one thing that was different and unify it.
And while we're at it, use IsFirstCommit() instead of counting parents.
