Bumps [github.com/spkg/bom](https://github.com/spkg/bom) from
0.0.0-20160624110644-59b7046e48ad to 1.0.1.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/spkg/bom/releases">github.com/spkg/bom's
releases</a>.</em></p>
<blockquote>
<h2>v1.0.1</h2>
<p>Update to later version of go, remove CI that no longer works</p>
<h2>v1.0.0</h2>
<p>Add support for Go modules.</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/spkg/bom/commits/v1.0.1">compare view</a></li>
</ul>
</details>
<br />
Bumps [github.com/adrg/xdg](https://github.com/adrg/xdg) from 0.4.0 to
0.5.3.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/adrg/xdg/releases">github.com/adrg/xdg's
releases</a>.</em></p>
<blockquote>
<h2>v0.5.3</h2>
<h3>Changelog</h3>
<ul>
<li>Updated <code>xdg.SearchRuntimeFile</code> to also look in the
operating system's temporary directory for runtime files.
This covers unlikely cases in which runtime files cannot be written
relative to the base runtime directory either because it does not exist
or it is not accessible, so <code>xdg.RuntimeFile</code> suggests the
operating system's temporary directory as a suitable fallback
location.</li>
</ul>
<h3>Internal</h3>
<ul>
<li>Improved package testing.</li>
</ul>
<h2>v0.5.2</h2>
<h3>Changelog</h3>
<ul>
<li>
<p>Updated logic of <code>xdg.RuntimeFile</code>: due to the special
nature of the <code>runtime directory</code>, the function no longer
attempts to create it if it does not exist. If that's the case, the
function uses the operating system's <code>temporary directory</code> as
a fallback. The function still creates subdirectories relative to the
base runtime directory or its fallback.</p>
<p>Justification: the creation of the runtime directory is not in the
scope of this package as it has special requirements defined by the <a
href="https://specifications.freedesktop.org/basedir-spec/latest">XDG
Base Directory Specification</a>. Relevant excerpt:</p>
<blockquote>
<p>The lifetime of the directory MUST be bound to the user being logged
in. It MUST be created when the user first logs in and if the user fully
logs out the directory MUST be removed. If the user logs in more than
once they should get pointed to the same directory, and it is mandatory
that the directory continues to exist from their first login to their
last logout on the system, and not removed in between. Files in the
directory MUST not survive reboot or a full logout/login cycle.</p>
</blockquote>
<p>Also, on <code>Linux</code>, the parent directories of the default
user runtime directory are owned by the root user so they cannot be
created by a regular user. <a
href="https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html">pam_systemd</a>
is usually responsible for creating the runtime directory
(<code>/run/user/$UID</code>).</p>
</li>
</ul>
<h2>v0.5.1</h2>
<h3>Changelog</h3>
<ul>
<li>Added support for the non-standard <code>XDG_BIN_HOME</code> base
directory.
See <a
href="https://github.com/adrg/xdg?tab=readme-ov-file#xdg-base-directory">XDG
base directories</a> README section for more details.</li>
<li>Added more config and data search locations on <code>macOS</code>.
<ul>
<li>Added <code>~/.config</code> at the end of the list of default
locations for <code>XDG_CONFIG_DIRS</code>.</li>
<li>Added <code>~/.local/share</code> at the end of the list of default
locations for <code>XDG_DATA_DIRS</code>.</li>
</ul>
</li>
<li>Added more application search locations on <code>Windows</code>:
<ul>
<li><code>%ProgramFiles%</code></li>
<li><code>%ProgramFiles%\Common Files</code></li>
<li><code>%LOCALAPPDATA%\Programs</code></li>
<li><code>%LOCALAPPDATA%\Programs\Common</code></li>
</ul>
</li>
</ul>
<h3>Internal</h3>
<ul>
<li>Updated <code>golang.org/x/sys</code> dependency to the latest
version.</li>
<li>Improved package testing.</li>
</ul>
<h2>v0.5.0</h2>
<h3>Changelog</h3>
<ul>
<li><code>user-dirs.dirs</code> config file is now parsed on Unix-like
operating systems (except for macOS and Plan 9).
See <a
href="https://github.com/adrg/xdg?tab=readme-ov-file#xdg-user-directories">XDG
user directories</a> README section for more details.</li>
<li>Updated <code>golang.org/x/sys</code> dependency to the latest
version.</li>
</ul>
<h4>Internal</h4>
<ul>
<li>Moved all path related functionality in internal
<code>pathutil</code> package.</li>
<li>Added internal <code>userdirs</code> package:
<ul>
<li>Moved <code>xdg.UserDirectories</code> to
<code>userdirs.Directories</code>.</li>
<li>Added parsing functions for <code>user-dirs.dirs</code> config
file.</li>
</ul>
</li>
<li>Improved package testing.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/adrg/xdg/commit/aa865a51a1b35fd06925fd6b8604991e79e3167e"><code>aa865a5</code></a>
Merge pull request <a
href="https://redirect.github.com/adrg/xdg/issues/101">#101</a> from
adrg/update-search-runtime-file</li>
<li><a
href="https://github.com/adrg/xdg/commit/71a81eccf3e9ac9ebf03e8c11ca3ed60a06eac7f"><code>71a81ec</code></a>
Minor xdg.SearchRuntimeFile function documentation update</li>
<li><a
href="https://github.com/adrg/xdg/commit/88111eba52ac2a211b97194266db5207c975c266"><code>88111eb</code></a>
Minor example update in README.md and doc.go</li>
<li><a
href="https://github.com/adrg/xdg/commit/d9f76be86d944bf2b9bdb8544952111e2533f3ad"><code>d9f76be</code></a>
Improve non-existent runtime directory test case</li>
<li><a
href="https://github.com/adrg/xdg/commit/800775a49c0a7877af5dca22104b90dc7e788cd0"><code>800775a</code></a>
Update xdg.SearchRuntimeFile to also look in temporary directory</li>
<li><a
href="https://github.com/adrg/xdg/commit/2335a687b19a49dafb193856d64d911d33c4b3c1"><code>2335a68</code></a>
Merge pull request <a
href="https://redirect.github.com/adrg/xdg/issues/99">#99</a> from
adrg/improve-runtime-file</li>
<li><a
href="https://github.com/adrg/xdg/commit/221e50698e5b31d277289e971f645299279efdd5"><code>221e506</code></a>
Minor non-existent runtime directory test case fix on macOS</li>
<li><a
href="https://github.com/adrg/xdg/commit/9bbb6024b2e9ee213bbed1f63ae8ea6063767d5b"><code>9bbb602</code></a>
Minor error format improvement in pathutil.Create and
pathutil.Search</li>
<li><a
href="https://github.com/adrg/xdg/commit/987b3ce5c440036b799a21a633a699be91530d0a"><code>987b3ce</code></a>
Minor README.md update</li>
<li><a
href="https://github.com/adrg/xdg/commit/3c39d559725cf005c392630100f4f338b49daf24"><code>3c39d55</code></a>
Add non-existent runtime directory test case</li>
<li>Additional commits viewable in <a
href="https://github.com/adrg/xdg/compare/v0.4.0...v0.5.3">compare
view</a></li>
</ul>
</details>
<br />
- **PR Description**
If the user has `gh` installed and is logged in (`gh auth login`),
lazygit shows GitHub PR icons next to the names of branches that have an
associated PR, colored by the PR's status (green=open, red=closed,
purple=merged).
Selecting a branch and pressing `shift-G` opens the PR in the browser.
For esthetic reasons, checking out a branch (or other ref) blocks the UI until
the refresh is done, so it's important that the refresh doesn't do unnecessary
work. Refreshing pull requests is unnecessary (but costly, when waiting for it)
when a branch is checked out that already existed locally. However, it is
required when checking out a remote branch for the first time, so that the PR
icon appears immediately when there is one.
For the branches panel we might consider unifying it with the existing `o`
command for creating a PR: it could check if there is a PR already, and open it
if so, or create a new one if not.
However, I also want the command in the local commits panel for the checked out
branch, and there's no existing "Create PR" command there; and the `o` command
opens the selected commit in the browser, so it's unrelated.
The only information that this carries is whether an entry is a real branch or a
detached head. Detached heads can only be at the top, and they are easy to tell
apart from the other branches by their name, so the icon is not really very
useful.
We are going to show PR icons in this column.
Not a terribly important feature for users, probably, but it is useful for
developers when testing a new feature with or without nerd fonts; and it does go
against or policy of all configs being hot-reloadable.
Note that switching from nerd fonts version 2 to 3 is *not* supported without
restarting, but I find this less important.
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.
When switching to a different repo, and then back to the original one,
searching would no longer work. The reason is that our contexts set
callbacks on their views; when switching to a different repo we
instantiate a new set of contexts, so they will overwrite the views'
callbacks with their new ones, but when switching back to the original
repo, we reuse the old contexts because they are still in memory, but
they won't set their callbacks again since they only do this on
construction.
To fix this, replace the view-local callbacks with a global one on the
gui that takes the view as an argument, so that the callback can look up
the associated context dynamically.
When switching to a different repo, and then back to the original one, searching
would no longer work. The reason is that our contexts set callbacks on their
views; when switching to a different repo we instantiate a new set of contexts,
so they will overwrite the views' callbacks with their new ones, but when
switching back to the original repo, we reuse the old contexts because they are
still in memory, but they won't set their callbacks again since they only do
this on construction.
To fix this, replace the view-local callbacks with a global one on the gui that
takes the view as an argument, so that the callback can look up the associated
context dynamically.
Remove our dependency on go-git, which was including a ton of
third-party code for very little benefit.
In addition, this fixes the problem that lazygit wouldn't show any
branches or remotes for certain types of malformatted .git/config files,
e.g. when there's a config section like `[branch ""]`, `[remote ""]`, or
`[-remote "xyz"]`; see #3901 and #5112.
### PR Description
This PR adds support for clicking on arrows in the file changes list
view, so that a mouse can be used to expand/collapse directories. This
enhancement was raised here as issue #5088.
We have some documentation for the corresponding setters in IBaseContext, but
that's part of the controller infrastructure and not client facing. For somebody
implementing a new view, this is where they will probably look for what methods
they can override.
When this was originally introduced, it handled single clicks on a list entry
(treating them similar to a double-click by checking whether the click was on
the selected entry). Arguably it should have been called OnDoubleClick back then
already; but when we later changed it to do actual double-click detection (see
37197b8e9a), we should have renamed the methods.
If the showDivergenceFromBaseBranch config is not none, the expanded
branches panel would no longer show the remote branch and subject; the
reason was that we padded the name all the way to the right edge of the
view so that the divergence information is right-aligned.
To fix this, we simply don't right-align the divergence in half or full
screen mode. This is a bit unfortunate, but it's hard to do any better,
because we don't know the width of our column in advance. One thing I
tried is to make the divergence a separate column in that case (with an
explicit right-alignment set on it via getColumnAlignments; however,
this makes it harder to properly truncate the name when the window is
too narrow.
If the showDivergenceFromBaseBranch config is not none, the expanded branches
panel would no longer show the remote branch and subject; the reason was that we
padded the name all the way to the right edge of the view so that the divergence
information is right-aligned.
To fix this, we simply don't right-align the divergence in half or full screen
mode. This is a bit unfortunate, but it's hard to do any better, because we
don't know the width of our column in advance. One thing I tried is to make the
divergence a separate column in that case (with an explicit right-alignment set
on it via getColumnAlignments; however, this makes it harder to properly
truncate the name when the window is too narrow.
Given a block of consecutive changed lines, staging only some of those
changes didn't always work. Consider the following scenario:
```diff
@@ -1,5 +1,5 @@
a
-b
-c
-d
+b'
+c'
+d'
e
```
Trying to stage only the change to "d" worked already as expected, but
staging either "b" or "c" didn't; the order of the deleted and added
lines in staged changes were wrong. We don't solve the "c" case in this
PR, as it's probably uncommon enough so that it doesn't matter too much,
and it seems to be quite a bit harder than the other two (and git gui
doesn't support it either, for the record). But we fix the "b" case
here, which is probably the most common one.
Fixes#5103.
This fixes the problem; a consequence of this change is that given the following
scenario:
@@ -1,3 +1,3 @@
1
-2
+2b
3
staging only the line `+2b` will put it *before* the unchanged `2` line, rather
than after it as you might expect (the changed unit tests demonstrate this).
Since this should be a pretty uncommon scenario, I guess it is an ok compromise.
As you can see in the changed tests, while the behavior of what gets staged is
fixed now, it doesn't always correctly select the next line to stage. We'll
address this in the next commit.
This is a pretty special case (see comment in the test for details). It is
working correctly, but I almost broke it during development, so it's good to
cover it with a test.
Given a block of consecutive changed lines, trying to stage only some of them
doesn't work correctly in all cases:
- if the staged lines are the last lines in the block of changes, it already
works
- when staging some changes in the middle of the block, it doesn't work as
desired, but we also don't try to fix this case in this branch, because it's
harder to do, and not as common as the other two
- staging the first lines of the block doesn't work as desired, and we will fix
that in this branch.
### PR Description
When a branch is checked out by another worktree, show the worktree name
in the label, e.g. "(worktree cosmos2)" instead of just "(worktree)", so
you can immediately see which worktree holds it.
When looking at a diff in diffing mode in the branches or tags panels
(e.g. after pressing `W` on a branch and then selecting a different
branch to diff it against the first one) it wasn't possible to change
the diff context size using `{` and `}`, or the rename threshold using
`(` and `)`.
Fixes#5254.
Actually, we simply enable them in any panel, even those that can never show a
diff. Since the commands show a toast, that's enough feedback to understand what
happened; the change will take effect the next time you switch to a panel that
does show diffs.
Same for ( and ) to change the rename threshold.
We did already have code to prevent clicks in inactive views behind a
popup, but it wasn't good enough. This PR fixes two problems:
- if the previously focused view (behind the panel) was a list view, it
would look like the click would select a different row, because gocui
would still set the view's cursor position, which is used to draw the
highlighted row
- it was still possible to click on tab headers, and this would dismiss
the panel
Fixes#5256.
This fixes two problems:
- if the previously focused view (behind the panel) was a list view, it would
look like the click would select a different row, because gocui would still
set the view's cursor position, which is used to draw the highlighted row
- it was still possible to click on tab headers, and this would dismiss the
panel
The symptom of the bug was that confirmation panels with wrapped text
were one character too wide, which could sometimes result in them being
one line too heigh. One concrete example is the "Discard file changes"
confirmation that appears when pressing `d` in the commit files panel.
I got confused when I investigated the bug that was fixed in the previous
commit, so hopefully these will be helpful for the next person reading this
code.
The symptom of the bug was that confirmation panels with wrapped text were one
character too wide, which could sometimes result in them being one line too
heigh. One concrete example is the "Discard file changes" confirmation that
appears when pressing `d` in the commit files panel.
I got very confused when investigating this bug, and the reason is that
getPopupPanelDimensionsAux took two parameters panelWidth and panelHeight, but
the second was actually contentHeight. Rename it to contentHeight, and change
the first one to also be the content width rather than the panel width. This is
easier for clients, and less confusing.
This commit implements the ability to cycle backward through different
all branches log visualization modes, complementing the existing forward
cycling functionality. Users can now press 'A' (Shift+a) to cycle in
reverse through the available log graph views, improving navigation
efficiency when they overshoot their desired view.
Stefan HallerandGitHub