This isn't a valid key, and according to claude it's not possible to configure
it to get only security updates (I'm too lazy to read the docs). I suppose this
means we will now get pull requests for any updated dependencies, but maybe
that's useful; we'll see how annoying this gets.
Re-submission of #5422. Had a problem with my fork and had to delete it,
which closed the original PR. Apologies for the noise.
## Summary
This PR pins all GitHub Actions to immutable commit SHAs and extracts an
inline secret from a `run:` block into an `env:` mapping.
- Pin 7 unpinned actions to full 40-character SHAs
- Extract 1 inline secret from run block to env var
## How to verify
Review the diff, each change is mechanical and preserves workflow
behavior:
- **SHA pinning**: `action@v3` becomes `action@abc123 # v3`, original
version preserved as comment
- **Secret extraction**: `${{ secrets.* }}` in `run:` moves to `env:`
block, referenced as `"${ENV_VAR}"` in the script
- No workflow logic, triggers, or permissions are modified
I've been researching CI/CD supply chain attack vectors and submitting
fixes to affected repos. Based on that research I built a scanner called
Runner Guard and open sourced it
[here](https://github.com/Vigilant-LLC/runner-guard) so you can scan
yourself if you want to. I'll be posting more advisories over the next
few weeks [on Twitter](https://x.com/vigilance_one) if you want to stay
in the loop.
If you have any questions, reach out. I'll be monitoring comms.
\- Chris (dagecko)
### PR Description
It actually expect `branch.<name>.*`
`man git-config | rg "\s+branch\.\S+\$"` to show all possible keys.
```
panic: runtime error: slice bounds out of range [7:6]
goroutine 57 [running]:
github.com/jesseduffield/lazygit/pkg/commands/git_commands.(*ConfigCommands).Branches(0x110187428260, {0x15495d0, 0x110187190230})
lazygit/pkg/commands/git_commands/config.go:104 +0x8ef
github.com/jesseduffield/lazygit/pkg/commands/git_commands.(*BranchLoader).Load(0x1101873e6180, {0x1d77440, 0x0, 0x0}, 0x1101873e86e0, {0x0, 0x0, 0x0}, 0x1, 0x1101872a5e60,
...)
lazygit/pkg/commands/git_commands/branch_loader.go:121 +0x7cc
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers.(*RefreshHelper).refreshBranches(0x1101871ef1c0, 0x1, 0x0, 0x1)
lazygit/pkg/gui/controllers/helpers/refresh_helper.go:456 +0x328
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers.(*RefreshHelper).Refresh.func2.3()
lazygit/pkg/gui/controllers/helpers/refresh_helper.go:131 +0x45
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers.(*RefreshHelper).Refresh.func2.1.1({0x154b438, 0x110187b12260})
lazygit/pkg/gui/controllers/helpers/refresh_helper.go:106 +0x30
github.com/jesseduffield/gocui.(*Gui).onWorkerAux(0x110187278b40, 0x110187a92190, {0x154b438, 0x110187b12260})
lazygit/vendor/github.com/jesseduffield/gocui/gui.go:713 +0x8b
github.com/jesseduffield/gocui.(*Gui).OnWorker.func1()
lazygit/vendor/github.com/jesseduffield/gocui/gui.go:700 +0x3f
created by github.com/jesseduffield/gocui.(*Gui).OnWorker in goroutine 1
```
### 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)
* [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
Add new config options for the sort order of files vs. directories, and
for sorting case sensitively or not.
Set the sort order's default from the former foldersFirst to mixed, so
this is a change in behavior. I find this useful because it now matches
git's order, so if you look at the diff of a commit, the TOC at the top
has the same order as the file tree you see when entering the commit.
Closes#4070.
Set the sort order's default from the former foldersFirst to mixed, so this is a
change in behavior. I find this useful because it now matches git's order, so if
you look at the diff of a commit, the TOC at the top has the same order as the
file tree you see when entering the commit.
When you rebase a branch and there are conflicts, lazygit asks you to
continue the rebase when it detects that all conflicts have been
resolved. However, it is common to make additional changes beyond just
fixing the conflicts (e.g. to fix build failures), and when doing that
while the "Continue the rebase?" prompt is showing, lazygit detects that
too and asks you if you want to stage those newly modified files too.
This is all well and good (and can be disabled for those who don't like
it); however, lazygit would treat out-of-date submodules as unstaged
changes and would offer to stage those as well, and this is pretty bad
and almost never what you want. Fix this by excluding submodules from
that second check.
When you rebase a branch and there are conflicts, lazygit asks you to continue
the rebase when it detects that all conflicts have been resolved. However, it is
common to make additional changes beyond just fixing the conflicts (e.g. to fix
build failures), and when doing that while the "Continue the rebase?" prompt is
showing, lazygit detects that too and asks you if you want to stage those newly
modified files too. This is all well and good (and can be disabled for those who
don't like it); however, lazygit would treat out-of-date submodules as unstaged
changes and would offer to stage those as well, and this is pretty bad and
almost never what you want. Fix this by excluding submodules from that second
check.
This is the same option as used by
pkg.commands.git_commands.diff.GetDiff().
This fixes some operations patch operation (tested with moving patch to
another commit) with `git config set --global color.ui always` (or
`color.diff always`).
The README says that this keybinding is ctrl+z, but the default
keybinding is shift+z — looks like this was changed in
376ca65807.
This PR updates the shortcut in the README to match the current
keybinding.
Previously, when showing subcommits of a branch or tag, scrolling down,
and then going out and entering subcommits again, it would select the
first commit but keep the previous scroll position, so that the
selection was not visible.
Previously, when showing subcommits of a branch or tag, scrolling down, and then
going out and entering subcommits again, it would select the first commit but
keep the previous scroll position, so that the selection was not visible. Always
scroll to the top to fix this.
When selecting a directory containing many changed files, or when
range-selecting many changed files, and then discarding them, this could
be so slow that lazygit appeared to hang; especially since there was no
UI feedback (e.g. a spinning status message).
This PR improves the performance greatly by batching the individual git
calls into a single one if possible. It still doesn't add UI feedback
though, hoping that the operation is now fast enough that it isn't
needed.
While we're at it, we fix a bug that would cause "Discard unstaged
changes" to discard more than just the visible files when filtering by
path.
Fixes#4581.
This is probably the less severe case, but it could still be an issue for people
who have many modified top-level files they want to discard, and have
showRootItemInFileTree set to false; they could select all those files by
pressing 'v' and '>'.
Previously it would iterate over all changed files and call git checkout or git
reset for each one, which can take forever if there are hundreds or thousands of
files. Now it batches these into a single command if possible (taking care of
still passing the individual path names to the git call rather than just the
directory, which is necessary for making it work correctly when filtering --
this was actually broken for the "Discard unstaged changes" command, which is
fixed here).
When discarding a directory, we only want to discard those files that are
visible in the current filter view. The tests show that this already works
correctly for discarding all changes, but it doesn't for discarding only
unstaged changes: in this case, untracked files are handled correctly, but
changes to tracked files are discarded without respecting the filter.
We have integration tests for this functionality, but those only test the
behavior, not the performance. In these unit tests you can see that we make
individual calls to git checkout and git reset for each file, which is very slow
when there are lots of files.
Previously it would only check that *if* removeFile was called, the passed
argument was the expected one; but it didn't check whether it was called at all.
Improve this by recording the file names that are removed, and checking them at
the end of each scenario.
This is going to be even more important for the tests that we are about to add
in the next commit, because for those there can be several calls to removeFile
in a single scenario.
dependabot[bot]
Stefan Haller
dagecko
phanium
Matthijs Kooijman
rohan436
John Yeates
Miika Tuominen