This is useful when cancelling out of the commit panel mid-sentence
(after having typed the space for the next word); when entering the
commit message panel again, the space was gone and you had to type it
again. Small thing, but it just seems better to resume the panel in
exactly the state that you left it in. (Which we actually don't do; we
don't remember the cursor position, or which of the subject/description
panels was active. That would be a separate improvement.)
Fixes#5519.
This is useful when cancelling out of the commit panel mid-sentence (after
having typed the space for the next word); when entering the commit message
panel again, the space was gone and you had to type it again. Small thing, but
it just seems better to resume the panel in exactly the state that you left it
in. (Which we actually don't do; we don't remember the cursor position, or which
of the subject/description panels was active. That would be a separate
improvement.)
The save path and the load path used to be asymmetric. On save, the textarea
getters applied strings.TrimSpace, which stripped any leading blank lines, a
trailing newline after the cursor, or indentation on the very first line of the
description — all of which are legitimate user content. On load,
SplitCommitMessageAndDescription did TrimSpace on the description as well, and
the preserved message was routed through that same git-format split because
HandleCommitPress passed it as OpenCommitMessagePanel's InitialMessage. The
result: every round-trip through "escape and reopen" silently mutated the
message.
The fix is to treat our own preservation file as its own format, distinct from
git's canonical "summary\n\nbody" format:
- The textarea getters return raw content. strings.TrimSpace moves to the one
place that still needs it: the empty-summary check in HandleCommitConfirm (git
itself strips trailing whitespace and blank lines, so no pre-trim is needed
before -m).
- SplitPreservedCommitMessage / SetPreservedMessageInView split on the single
"\n" our Join uses, without any trimming — truly lossless.
- SplitCommitMessageAndDescription keeps its git-format behavior but replaces
TrimSpace with TrimPrefix("\n"), so it strips only the blank-line separator
and leaves body indentation intact.
- HandleCommitPress now mirrors HandleWIPCommitPress: it no longer passes the
preserved message as InitialMessage. OpenCommitMessagePanel resolves the
preserved content itself, uses it for display via the preservation-format
setter, and stores it as the initial message so the close-time "did the user
change anything?" check still correctly detects a cleared panel.
- GetInitialMessage no longer trims. With raw getters on both sides of the
comparison, trimming here caused spurious non-matches (e.g. for preserved
content with trailing whitespace). The original motivation — matching a
"WIP: " prefix with trailing space — works unchanged.
- UpdateCommitPanelView becomes dead code and is removed; its one remaining
caller (history cycling, always git-format) goes directly through
SetMessageAndDescriptionInView.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Callers currently hand this function a trimmed description, so the output is
always clean. An upcoming change to the commit-panel getters will stop trimming
at the callsite (so that whitespace typed by the user round-trips through the
preservation file exactly), at which point the description can end with one or
more newlines. Without this change, a user who presses Enter after their
description body and then invokes "Add co-author" would end up with two blank
lines between the body and the trailer instead of the expected one.
Git's --grep option uses Basic Regular Expression syntax by default, which means
that the `[^\n]*` didn't do what was intended; it means "any character except
`\` or the literal letter `n`" — not "any character except newline."
Besides, `^` matched any line start, not only the start of the entire message,
so "any character except newline" would have been wrong anyway. Given this, the
script matched commits that have WIP or DROPME in the body, which is not what we
want. (The last commit of this branch is an example for that.)
Fix this by listing only the subject lines and grepping them outside of git;
this also lets us use a slightly simpler regex (we want to match WIP anywhere in
the subject).
This isn't possible with the default quit binding ('q'), but there's an
alternative binding (ctrl-c) that does work while the panel is open;
also, users can rebind quit to something like ctrl-q.
Fixes#5513.
This isn't possible with the default quit binding ('q'), but there's an
alternative binding (ctrl-c) that does work while the panel is open; also, users
can rebind quit to something like ctrl-q.
We'll want to call just the preservation step when the app is quitting
with the commit message panel open: at that point the view-hiding and
context-popping in CloseCommitMessagePanel are pointless (the app is
about to exit), and some of the focus-lost side effects could be
surprising during teardown.
There's no reason for this; when opening the panel next time, it will be
populated again. Also, it doesn't make sense to do this only when not preserving
the message.
Related to #5124
## Changes
- Extended existing retry logic to handle transient ref lock errors
- Added retry for "cannot lock ref" and "cannot update ref" error
messages
- Extracted retryable error check into helper function for clarity
These errors can occur intermittently during fetch/pull operations on
large repositories and typically succeed on retry.
Extends the existing retry logic to handle transient lock-related errors beyond just .git/index.lock. This now also retries when encountering "cannot lock ref" or "cannot update ref" errors, which can occur intermittently during fetch/pull operations in large repositories.
Related to #5124
Signed-off-by: majiayu000 <1835304752@qq.com>
Change the tests so that they run in a linked worktree; this uncovers the bug
that copying a file's absolute path uses the main repo path rather than the
worktree's path.
When no base repository is configured using gh, we have several
heuristics for choosing a likely base repo before prompting the user.
One of these was that if the origin remote exists, we'd choose that.
This may be the right choice in some cases, but in many others it's not;
for example, in the common scenario of a forking setup where the
upstream repo's remote is called after its owner, and the fork remote is
called origin, we would choose origin as the base repo, which results in
not showing any PRs. Don't do that, and instead prompt the user for the
base repo in this case.
When no base repository is configured using gh, we have several heuristics for
choosing a likely base repo before prompting the user. One of these was that if
the origin remote exists, we'd choose that. This may be the right choice in some
cases, but in many others it's not; for example, in the common scenario of a
forking setup where the upstream repo's remote is called after its owner, and
the fork remote is called origin, we would choose origin as the base repo, which
results in not showing any PRs. Don't do that, and instead prompt the user for
the base repo in this case.
The assumption is that if a pull request exists on a main branch, it was
usually created by mistake and then closed, and showing it serves no
purpose and is only distracting.
We keep showing _open_ pull requests for main branches though, because
this allows you to notice that there is one that you probably want to
close.
This only affects the display (in the branches list and in the main
view); opening the PR in the browser using shift-G is still possible, as
is copying its URL to the clipboard.
The assumption is that if a pull request exists on a main branch, it was usually
created by mistake and then closed, and showing it serves no purpose and is only
distracting.
We keep showing open pull requests for main branches though, because this allows
you to notice that there is one that you probably want to close.
This only affects the display (in the branches list and in the main view);
opening the PR in the browser using shift-G is still possible, as is copying its
URL to the clipboard.
### PR Description
Close#5494
Normalizes the repository owner to lowercase during the PR mapping.
This ensures that PR icons and integration features work correctly even
when the local git remote URL casing differs from the official
repository casing on GitHub.
Normalizes the repository owner to lowercase during the PR
mapping.
This ensures that PR icons and integration features work correctly even
when the local git remote URL casing differs from the official
repository casing on GitHub.
Just (https://just.systems/) works better than make for running
commands. For example, passing arguments to `make integration-test-cli`
requires a `--` between make's arguments and the cli test runner's
arguments (e.g. -sandbox), and will also result in weird errors. Just
doesn't have any of these problems.
I chose different target names than we use in the Makefile; the goal is
to have better tab completion, where the most commonly used commands can
be completed after typing a single letter. That's why I use "e2e" for
integration tests, which is not a term we use anywhere else.
Keeping the Makefile around for those who are used to it, and are too
lazy to install just.
Just (https://just.systems/) works better than make for running commands. For
example, passing arguments to `make integration-test-cli` requires a `--`
between make's arguments and the cli test runner's arguments (e.g. -sandbox),
and will also result in weird errors. Just doesn't have any of these problems.
I chose different target names than we use in the Makefile; the goal is to have
better tab completion, where the most commonly used commands can be completed
after typing a single letter. That's why I use "e2e" for integration tests,
which is not a term we use anywhere else.
Keeping the Makefile around for those who are used to it, and are too lazy to
install just.
## Summary
Fix high severity security issue in `.github/workflows/release.yml`.
## Vulnerability
| Field | Value |
|-------|-------|
| **ID** |
yaml.github-actions.security.run-shell-injection.run-shell-injection |
| **Severity** | HIGH |
| **Scanner** | semgrep |
| **Rule** |
`yaml.github-actions.security.run-shell-injection.run-shell-injection` |
| **File** | `.github/workflows/release.yml:113` |
**Description**: Using variable interpolation `${{...}}` with `github`
context data in a `run:` step could allow an attacker to inject their
own code into the runner. This would allow them to steal secrets and
code. `github` context data can have arbitrary user input and should be
treated as untrusted. Instead, use an intermediate environment variable
with `env:` to store the data and use the environment variable in the
`run:` script. Be sure to use double-quotes the environment variable,
like this: "$ENVVAR".
## Changes
- `.github/workflows/release.yml`
## Verification
- [x] Build passes
- [x] Scanner re-scan confirms fix
- [x] LLM code review passed
---
*Automated security fix by [OrbisAI Security](https://orbisappsec.com)*
When building multi-step custom command forms, some prompts are only
relevant depending on earlier answers. Without conditional logic, users
must dismiss irrelevant prompts manually.
Prompts now accept a `condition` field with a template expression
evaluated against prior form values. Skipped prompts default to an empty
string.
When building multi-step custom command forms, some prompts are only
relevant depending on earlier answers. Without conditional logic,
users must dismiss irrelevant prompts manually.
Prompts now accept a `condition` field with a template expression
evaluated against prior form values. Skipped prompts default to
an empty string.
The template expression is a string pre- and suffixed with double curly
braces - {{}}.
Form keys can be reused, a guard ensures that skipped prompts do not
reset already set form keys with an empty string. This allows the
conditional flow to remind a user to set a key that was left empty
because additional conditions want that key to be set. This removes the
need to have additional if checks in the command that uses the form
keys.
This makes it easier to recover them if they were deleted accidentally.
We only do this for local branches for now, we don't bother for remote
branches; it would be trickier there, because the branch on the server
might not actually point to the same hash as our local remote tracking
branch does.
Fixes#2468.
This makes it easier to recover them if they were deleted accidentally.
We only do this for local branches for now, we don't bother for remote branches;
it would be trickier there, because the branch on the server might not actually
point to the same hash as our local remote tracking branch does.
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 />
github-actions[bot]
Stefan Haller
majiayu000
Bradly Chang
Ubuntu
Martin T.
dependabot[bot]