Repository navigation
gh "base repository" not worktree specific #1837
Description
Activity
@davezarzycki Hi, thanks for writing in! You are right that right now, a "base" repo will be saved per git repository (not per-branch or per-worktree). You are also right that the base repository feature is currently undocumented.
To help me understand your use case: when you switch between branches/worktrees, how would you prefer the "base" repo being selected for querying issues or choosing a base repository for newly created PRs?
I'd just formalize the workaround listed above: if the local branch has an upstream/tracking branch, then extract the "remote" of the upstream branch and use that as the GitHub "base".
This approach implicitly works with git worktrees.
I'm not sure that this is a bug; it seems like more of a desired enhancement around
gh's awareness of a user using multiple worktrees. Re-labeling as such.The title of this isn't great. Sorry. This open issue is also about working with multiple remotes too, not just multiple worktrees.
@davezarzycki Thanks for getting back to us! More specifics would be really useful for us to understand how we can improve gh in this manner. For example: in a local repository with remotes X and Y, when in a worktree so-and-so, I expect
gh <command>to query information from GitHub repo Z.Hi @mislav — On Oct 16th, you asked what I thought
ghshould do, and I replied "just formalize the workaround" (i.e. implement the workaround I described earlier ingh). If I might repeat myself using different words:If the
GH_REPOenvironmental variable is not explicitly set, then derive the value as much as possible at runtime. If the active / checked out branch has an upstream/tracking branch, then extract the repository from that and use it. Otherwise, if an upstream/tracking branch does not exist and only one remote is defined, then use that.This logic doesn't require any special handling to make worktrees work as a bonus. :-)
Am I missing something about what more information you want?
gh version 1.0.0 (2020-09-16)
Setup: a "bare" git repository with multiple remotes and multiple git worktrees. For example: both https://github.com/llvm/llvm-project and https://github.com/apple/llvm-project
Problem: Unlike similar git workflows,
ghasks the user to pick a "base repository" which is tied to the bare repository, not branches nor worktrees.Workaround: create a wrapper around
ghthat tries to setGH_REPOas needed. In short, the script will extract the GitHub URL from git and pass it to gh:git config remote.$(git config branch.$(git branch --show-current).remote).urlFinally, and unless I missed something, the "base repository" feature seems undocumented.