Re: Worktree shares a common remote with main checkout
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@gmail.com> wrote:
Show 58 quoted lines
>
> 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
