- reorder if checks: validate --enable-squash-merge is set before
checking the value, and error when --enable-squash-merge=false
- use validSquashMsgValues directly in interactive prompt instead of
duplicating the slice
- use slices.Contains in validateSquashMergeCommitMsg
- interpolate const values in Long description instead of hardcoding
- add default clause in transformSquashMergeOpts to avoid mutating
title/message on unknown input
- move optionDiscussions to end of const block with TODO comment
- add test for unknown input and --enable-squash-merge=false case
Add a single --squash-merge-commit-message flag that maps to both
squash_merge_commit_title and squash_merge_commit_message API fields.
Supported values:
- default: COMMIT_OR_PR_TITLE + COMMIT_MESSAGES
- pr-title: PR_TITLE + BLANK
- pr-title-commits: PR_TITLE + COMMIT_MESSAGES
- pr-title-description: PR_TITLE + PR_BODY
The flag requires --enable-squash-merge to be set alongside it. In
interactive mode, the squash merge commit message prompt appears when
squash merging is selected.
Closes#10092
Add greppable TODO identifiers above all if-statements that reference
featuredetection struct fields, as required by the featuredetection
linter. This ensures every feature detection branch is tagged for
future cleanup when GHES gains support.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When cloning a forked repository, `gh repo clone` automatically adds the
parent repo as an `upstream` remote and sets it as the default repository.
This can be problematic when the user lacks access to the parent repo,
the upstream fetch is expensive for large repos, or the user simply
doesn't want the upstream remote.
Add a `--no-upstream` flag that skips adding the upstream remote when
cloning a fork. When used, origin (the fork) is set as the default
repository instead. The flag is mutually exclusive with
`--upstream-remote-name`. For non-fork repos the flag is a harmless
no-op.
Closes#8274
When specifying a repository for `gh repo set-default`, users can now
use a git remote name (e.g., "origin", "upstream") instead of the
full OWNER/REPO format.
The command first checks if the argument is a git remote name. If
found, it uses the corresponding repository. Otherwise, it falls
back to parsing the argument as OWNER/REPO format.
Example:
gh repo set-default origin
Fixes#9149
Signed-off-by: majiayu000 <1835304752@qq.com>
When a repository argument is provided to `gh repo fork`, the command
operates independently of the current local repository. Using --remote
in this context is incompatible because there's no local repository to
add the remote to.
This change returns an explicit error when these flags are combined,
providing clear feedback instead of silently ignoring the --remote flag.
Fixes#2722
Signed-off-by: majiayu000 <1835304752@qq.com>
The returned response from `api.EndpointNeedsScopes` causes `bodyclose`
linter to raise a false positive error, assuming it's a new response that
its body needs to be closed.
Signed-off-by: Babak K. Shandiz <babakks@github.com>
Outside of the hostnames previously fixed, I talked with @williammartin about what to do with the remaining references and the concern about the mixed format.
One suggestion for the error / test use case was to remove the extraneous text all together.
This commit changes <github.com> and <ghe.com> references to `github.com` and `ghe.com` so they are visible on the GitHub CLI marketing website.
GitHub Pages will render URLs with a protocol as clickable links, however hostnames are treated as HTML elements and not rendered.
This commit converts all of the places using ColorScheme.Gray and ColorScheme.Grayf to Muted and Mutedf.
There is a little extra tidying up with local variable names or converting code to use Mutedf format.
After discussing this with the team, the `gh config` changes to display `accessible_colors` have been removed from this branch being outside of acceptance criteria. This will be moved to a separate issue along with any other work needed to finalize the public preview such as `gh help` entries for `GH_ACCESSIBLE_COLORS` environment variable.
List commands that use ColorScheme.Gray have been updated to use ColorScheme.Muted.
Follow up of https://github.com/cli/cli/pull/7612
The `missingWorkflowScopeRE` is defined to capture
the error message when the `GH_TOKEN` does not have
`workflow` scope in `gh repo sync <remote>`,
but this is only intended for error messages for
OAuth Apps and does not work with GitHub Apps.
In GitHub App, you will get the following error:
```
{
"message": "refusing to allow a GitHub App to create or update workflow `.github/workflows/teamcity-pr-checks.yml` without `workflows` permission",
"documentation_url": "https://docs.github.com/rest/branches/branches#sync-a-fork-branch-with-the-upstream-repository",
"status": "422"
}
```
As you can see above, the existing regexp does not
match the "`workflows` permission".
This change modifies the regexp to return
the user-friendly error message when the `workflow`
permission is missing, even in the case of a GitHub App.
`gh repo rename` can only rename a repo, but not change its owner
(i.e. transfer it).
As flagged in #10034, at the moment, the CLI behaves like it can do
this, and produces weird results.
If I ask to rename my repo to `polyseam/frappe-containers`:
```bash
gh repo rename polyseam/frappe-containers
```
..the preview suggests that it will do the right thing:
```
? Rename polyseam/containers to polyseam/frappe-containers? Yes
```
...but the repo gets renamed wrongly:
```
✓ Renamed repository polyseam/polyseam-frappe-containers
```
This adds an upfront validation that looks for a slash and tells
you that the command can't transfer a repo.
Fixes#10034.
