- **PR Description**
In version 0.45.0 we started to use an interactive shell for running
shell commands (see #4159). The idea was that this allows users to use
their aliases and shell functions in lazygit without having to do any
additional configuration.
Unfortunately, this hasn't worked out well. For some users this resulted
in lazygit hanging in the background upon trying to return from the
shell command; we tried various fixes for this (see #4126, #4159, and
#4350), but some users still have this problem (e.g. #4320).
Also, starting an interactive shell can be a lot slower than starting a
non-interactive one, depending on how much happens in the `.bashrc` or
`.zshrc` file. For example, on my machine calling `zsh -ic true` takes
600ms, whereas `zsh -c true` takes less than 2ms. This is too high of a
price to pay for using shell aliases, especially when _all_ users have
to pay it, even those who don't care about using their aliases in
lazygit.
This PR reverts all commits related to interactive shells, and instead
introduces a different approach: we let users specify a shell aliases
file that will be sourced before running a command. The downside is that
it doesn't work transparently out of the box, but requires
configuration, and it may also require that users restructure their
shell startup file(s) if they currently only have a single big one. The
advantage is that only users who actually want to use aliases or
functions are affected, and that we can now use this mechanism not only
for shell commands, but also for custom commands and for calling the
editor (some users have asked for this in the past).
There is a section at the end with deprecated settings, and a comment saying
"The following configs are all deprecated". The clipboard-related settings were
accidentally added to that section; they are not deprecated, so move them up to
before that section.
- **PR Description**
This PR addresses https://github.com/jesseduffield/lazygit/issues/3951.
The current rules for discarding submodule changes is that no other
changed item must be also selected. There are some bugs with the current
implementation when submodules are in folders. The filed issue goes into
more detail.
As part of this PR, I also tentatively changed the disabled message
("Range select not supported for submodules" -> "Multiselection not
supported for submodules"). The former was not quite accurate because
you could select a single line (folder) but the reset action still needs
to be disabled (folder contains submodule change and some other change).
Not sure if there is some better phrasing.
The current rules for discarding submodule changes is that no other changed item
must be also selected. There are some bugs with the current implementation when
submodules are in folders.
For example, selecting and discarding a folder with only a nested submodule
change will currently do nothing. The submodule changes should be discarded. The
folder only contains submodule changes so it should be no different than
pressing discard on the submodule entry itself.
Also, I noticed range selecting both the folder and the submodule and then
pressing discard would be incorrectly disallowed.
Renaming a file inside the same directory shows it with its full path in the
tree view, which isn't what we want. We'll fix this in the next commit.
Also adding a few other test cases for moving files; they show that the display
of moved files in tree view isn't ideal. For example, moving file1 from top
level into dir shows it as "R file1 → file1", which isn't distinguishable from
renaming file1 inside dir. I suppose what we would like to have here is
"R ../file1 → file1" or something, but I'll leave that for the future; here I
only want to fix the regression that was introduced with the root item PR.
- **PR Description**
The integration test `stash/rename.go` occasionally fails for me
locally. This PR fixes it.
In 8b8343b8a9f we made a change to run newPtyTask from AfterLayout; this
is needed so that the PTY gets the new, updated view size. However, this
created a race condition for integration tests that select a line in a
list view and then expect the main view to have certain content;
sometimes that content gets rendered too late.
I'm surprised that this didn't cause more tests to fail; right now I
only know of one test that occasionally fails because of this, which is
`stash/rename.go`.
Fix this by moving the AfterLayout to inside newPtyTask, and do it only
when we are actually using a PTY (we don't when no pager is configured,
which is the case for integration tests).
The diff is best viewed with "ignore whitespace" turned on.
In 8b8343b8a9f we made a change to run newPtyTask from AfterLayout; this is
needed so that the PTY gets the new, updated view size. However, this created a
race condition for integration tests that select a line in a list view and then
expect the main view to have certain content; sometimes that content gets
rendered too late.
I'm surprised that this didn't cause more tests to fail; right now I only know
of one test that occasionally fails because of this, which is stash/rename.go.
Fix this by moving the AfterLayout to inside newPtyTask, and do it only when we
are actually using a PTY (we don't when no pager is configured, which is the
case for integration tests).
The diff is best viewed with "ignore whitespace" turned on.
- **PR Description**
* The keybind for moving a commit up in the interactive rebase example
of the README file is incorrect.
I've changed it to the keybind present in current versions of Lazygit
- **PR Description**
When selecting a range of commits by selecting the top one and then
pressing shift-down to create a range, and then pressing enter and
checking out one of the files by pressing `c`, you would get the file
checked out with its state at the bottom end of the range, which is not
what you want; it is expected to check out the file at the state that
the diff shows it changes to. (And if the file was only created in the
middle of that range, trying to check it out would result in an error.)
Fix this by paying attention to a "from-to" range selection, and
checking out the file at the "to" state.
Related to #4420.
The test shows a misbehavior: even though the diff shows "-one" and "+three",
meaning that "three" is the state we want to check out, we get "one". The reason
is that the checkout file command doesn't pay attention to range selections, it
only looks at the "moving end" of the range. Had we created the range by
selecting "two" and then pressed shift-up to "three", we would have gotten the
expected result.
- **PR Description**
When using gpg signing on tags via the git config `tag.gpgSign=true`, it
is not possible to do a lightweight tag. You must do an annotated tag
(Which is allowed to have an empty description).
This PR augments the existing `WithGpgHandling` helper to allow it to
specifically target commit signing and tag signing. It then uses that
handler, and creates an annotated tag, when the git config demands tag
GPG signing. By default it will launch the tag signing in a new
subprocess. This does require that users click an extra `<enter>` after
creating a signed tag, but this is currently the behavior for signed
commits, so I don't feel too bad about that. If they want, they can use
the LazyGit configuration option of `git.overrideGpg: true` to promise
to LazyGit that they do not need a GPG sub-process (because they
reliably already have gpg-agent or similar running in the background).
This again matches the current behavior for GPG signed commits.
This has no integration test because we don't have the machinery set up
in place to set up a GPG key inside of our integration test framework.
Fixes https://github.com/jesseduffield/lazygit/issues/2955
The actual usage is case insensitive, so this doesn't actually matter.
But if fills my heart with joy.
The test is case sensitive, but the actual response to `git config
commit.gpgSign` is equivalent to `git config commit.gppsign`
- **PR Description**
This removes generated Config.md entries that are contain the word:
`deprecated` (case insensitive) anywhere in their header comment.
I think adding in deprecated configs into the reference config clutters
it at best, and encourages users to use those configs at worst. They are
still going to be validated by the schema, but this PR removes them from
the generated config.
I also added in the missing `deprecated` yaml tags in our user config in
anticipation of https://github.com/invopop/jsonschema/pull/79 getting
merged.
- **PR Description**
Include empty arrays and maps in the generated Config.md
It's not an ideal solution because there's no indication of what kind of objects
you can add to those maps or arrays, but at least they show up at all (with a
comment containing a link to more information), and that's already an improvement.
It's not an ideal solution because there's no indication of what kind of objects
you can add to those maps or arrays, but at least they show up at all (with a
comment containing a link to more information), and that's already an
improvement.
As discussed in #1984, this PR modifies the code such that the `w`
command always commits without pre-commit hooks. The `skipHookPrefix` is
still considered when starting the commit messaged with the prefix in
the regular commit command using `c`.
Skipping pre-commits also works when switching to the editor and adding
a co author from the the `w` command
Add verify flag
Add and update integration tests
Rename verify to forceSkipHooks
Adapt CommitSkipHooks integration test to actually use a hook
Remove forceSkipHooks param from OnConfirm et al
Simplify tests
- **PR Description**
This PR adds a new bulk action for submodules.
As I often work with a lot of submodules that are hierarchically
structured, the flag "--recursive" saves a lot of work.
- **PR Description**
Since they started releasing .0 versions with 1.21.0, the go version
need to be a full release version specifier and not a go language
version. They relented and added support for defaulting to a .0 release
if none is specified in later 1.23.x releases, but for users with local
1.21 or 1.22 toolchains the lack of a full release specifier breaks
them. And going forwards this is more technically correct anyway.
See https://github.com/golang/go/issues/62278#issuecomment-1693620853
Since they started releasing .0 versions with 1.21.0, the go version
need to be a full release version specifier and not a go language
version. They relented and added support for defaulting to a .0 release
if none is specified in later 1.23.x releases, but for users with local
1.21 or 1.22 toolchains the lack of a full release specifier breaks
them. And going forwards this is more technically correct anyway.
See https://github.com/golang/go/issues/62278#issuecomment-1693620853
