Each branch has a parent origin/remote repository that it is directly tracking (or not tracking), but there are other operations that presume the name "origin" as the name - the two that I care about are: git fetch - this should be able to default fetch a remote associated with the worktree git push (on a new branch) says: git push --set-upstream origin testBranch I want this to say git push --set-upstream project1-remote testBranch instead. Ideally, adding this automatically should set the upstream remote to the specified upstream branch if that is configured (which I never do, since I often switch the upstream). Ideally supposing there are two branches origin/main and project1-remote/main, then doing: git checkout main in worktree project1 would checkout project1-remote/main while doing it in the original checkout would checkout origin/main There is no change to the functionality of worktree branches, the only change is the ability to store configuration values associated with a worktree (not a branch, but the worktree itself), plus getting the name "origin" from configuration instead of defaulting to "origin" The setting `checkout.defaultRemote` is close - but I want that to be something like: worktree.<name>.remote=<value> eg worktree.project1.remote=project1-remote and then: git fetch will fetch from project1-remote when in project1 worktree With git push having auto setup remote, this will default to pushing a branch testBranch to project1-remote/testBranch and without it being auto setup, will show the message: "git push --set-upstream project1-remote testBranch" as specified above. git checkout nonLocalBranch will first try to get nonLocalBranch from project1-remote, and only if it is ambiguous on other systems would it complain. Bill On Wed, 3 Apr 2024 at 13:24, Brian Lyles <brianmlyles@xxxxxxxxx> wrote: > > Hi Bill, > > Phillip Wood wrote: > > > You can set a different default remote for "git pull" for each branch by > > setting an upstream branch with "git branch --set-upstream-to" which > > sets "branch.<name>.remote" and "branch.<name>.merge" or > > "branch.<name>.rebase". You can also set a different remote to push to > > by setting "branch.<name>.pushRemote" - see the "git config" > > documentation. Would that help? > > Bill Wallace wrote: > > > It helps, and I do that, but I really want it associated with the > > worktree so that I can work on projects for different vendors based on > > a common open source framework. What I'm trying to avoid is > > accidentally committing a branch to the wrong vendor's stream or > > mixing changes between streams. > > My understanding of worktrees has always been that they are simply a > checkout of an arbitrary branch, and that branches themselves define > their remote as Phillip noted. > > I'm struggling to reconcile this fact of a branch defining its remote > with having a worktree also define the remote. How would this be > expected to behave if you try to switch a worktree with some defined > remote to a branch based on another remote? A warning or error? > > I am also wondering if an adjustment to your branch creation/management > would solve this problem without needing such a significant change to > the definition of a worktree. > > At the point of branch creation, the branch will track a specific remote > based on the ref it's created from (assuming that ref is a remote > tracking ref, and based on your `branch.autoSetupMerge`/whether > `--track`/`--no-track` is used). The remote can be corrected after > creation as Phillip noted. > > For example: My understanding is that if you were to set your > `branch.autoSetupMerge` to `inherit`, then when you create a new branch > it would inherit the remote tracking ref (and therefore the remote) from > the branch that you create it from. This would be the case whether you > specify a ref manually at the time of creation, or just omit it to > create the branch from the current checked out branch. If the latter, > then by creating new branches from within the worktree that you > designated for a specific vendor/stream, you ensure that the new branch > uses that same remote. > > Have you tried that approach? `branch.autoSetupMerge` has > several other values to control this behavior as well though `inherit` > seems closest to what you're looking for to me. If this is still > insufficient, I'd be curious to hear more specifics about where it > breaks down. > > -- > Thank you, > Brian Lyles
