Repository navigation
gh pr checkout defies negative refspec in remote.*.<name> #10254
Description
Activity
👋 Hey @Frederick888, thanks for this issue ✨
I started digging into this, and what may be happening is that when you provide a command line refspec to
git fetchthe refspec(s) in your Git config are ignored:Specifies which refs to fetch and which local refs to update. When no
<refspec>s appear on the command line, the refs to fetch are read fromremote.<repository>.fetchvariables insteadSince we need to provide a refspec on the command line to checkout the PR, I am not sure what options are available to us in
gh. Perhaps getting the config and appending it to the command line refspec?I saw that you could configure the default tag fetch policy, which may help preventing tags from being fetched generally - though I recognize that's not exactly what you're looking for:
--no-tags
By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally. This option disables this automatic tag following. The default behavior for a remote may be specified with theremote.<name>.tagOptsetting. See git-config[1].💭 All this in mind, I think this is intended behavior.
Please let me know if I understood correctly and if you have any other ideas or feedback 😁❤
- addedenhancementa request to improve CLIa request to improve CLImore-info-neededMore info needed from user/contributorMore info needed from user/contributorand removedbugSomething isn't workingSomething isn't working
on Jan 17, 2025 @BagToad Git's behaviour is a bit confusing. With my config, somehow
$ git fetch origin # will fetch *-deploy tags $ git fetch --tags origin # will NOT fetch *-deploy tags $ git fetch --no-tags origin # will NOT fetch ANY tags $ git fetch origin '+refs/heads/feat-branch:refs/remotes/origin/feat-branch' # so while this will fetch *-deploy tags $ git fetch --tags origin '+refs/heads/feat-branch:refs/remotes/origin/feat-branch' '^refs/heads/*-deploy' '^refs/tags/*-deploy' # ...this will not fetch *-deploy tags (but other tags will be fetched, which can be considered expected)
So I think when a PR is from an existing remote in
.git/config, we can add--tags+ process the output ofgit config --get-all remote.origin.fetchto append the additional negative refspecs.- removedmore-info-neededMore info needed from user/contributorMore info needed from user/contributor
on Jan 21, 2025 I can't think of a reason we would need tags for
pr checkoutsince PRs are based entirely around branches.Can you think of a reason we shouldn't just provide
--no-tagsto thegit fetchcommand here?- addedmore-info-neededMore info needed from user/contributorMore info needed from user/contributorgh-prrelating to the gh pr commandrelating to the gh pr command
on Jan 23, 2025 @williammartin Yup that works for me too!
I wasn't sure about how the code was structured and whether the
git fetchcommand was reused in any way. But in terms ofgh pr checkout,--no-tagssounds good to me 👍Acceptance Criteria
Given I have a repository with Git tags
When I rungh pr checkout
Then the branch is fetched with--no-tags- addedhelp wantedContributions welcomeContributions welcomeand removedmore-info-neededMore info needed from user/contributorMore info needed from user/contributorneeds-triageneeds to be reviewedneeds to be reviewed
on Feb 5, 2025
Describe the bug
We have some release Actions that push artefacts to
v123-deploywhenv123tag is created. I never need the*-deploytags, so to avoid fetching them, in my.git/config:However if I do a
gh pr checkout 123456, it'll fetch all those*-deploytags.Steps to reproduce the behavior
gh pr checkout 123456Expected vs actual behavior
ghrespects myremote.*.<name>configs.Logs
Paste the activity from your command line. Redact if needed.