Re: Worktree shares a common remote with main checkout

[Bill Wallace <wayfarer3130@gmail.com>]

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:
>
> 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