Re: Worktree shares a common remote with main checkout

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Bill

On 03/04/2024 15:26, Bill Wallace wrote:
> The problem is that one wants different default remotes for different
> worktrees - for example, suppose I'm creating a worktree for two
> different projects, plus the base repository is on the "origin"
> default remote.  I then have:
> base_repository - a directory with the base/default origin (call it
> 'origin' for now as the remote name)
> project1 - currently checked out with 'feat/1'
> project2 - current checkout out with 'feat/2'
> 
> Now, project1 is being developed against a remote repository
> 'project1-origin' and project2 is being developed against a remote
> repository 'project2-origin'
> However, both are getting merges from origin/main on their own
> projectX-origin/main branches
> 
> Now, when I'm the directory for project1 and I do any of:
>     git fetch
>     git checkout X
>     git push
> 
> I want the correct default to be chosen for the remote - for the
> base_repository that should be 'origin', while for project1 it should
> be 'project1-origin' etc.

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?

Best Wishes

Phillip

> I KNOW I can specify those manually, and git push will give a
> suggestion, but I WANT all of them to default to the correct remote
> associated with that worktree so that I don't accidentally pick the
> wrong one or forget to update the correct repository.  This is to fix
> dumb fingers that sometimes do the wrong thing without thinking, and
> to try to reduce the number of things that don't get done
> accidentally.
> 
> What I'm doing now is to create a new non-worktree version against the
> projects directories, but that then doesn't share any data.
> 
> git remote add ... has nothing to do with this, but I want something like:
> 
> git worktree add project1 --default-remote project1-origin
> 
> The idea is to make the expectations of what happens to be consistent
> with cloning a new directory, or at least as close as possible to
> that.
> 
> Bill.
> 
> On Fri, 22 Mar 2024 at 13:29, Kristoffer Haugsbakk <code@khaugsbakk.name> wrote:
>>
>> On Fri, Mar 22, 2024, at 15:50, Bill Wallace wrote:
>>> This issue is just to fix an easy to make mistake when working with
>>> multiple remote origins and worktrees, where it is too easy to push to
>>> the wrong remote origin because one can't set the default origin on a
>>> per-worktree basis.
>>>
>>> What did you do before the bug happened? (Steps to reproduce your issue)
>>> Used
>>> * git worktree to create a worktree
>>> * git remote add to add a custom repository
>>> * git commit/push to try to push changes
>>>
>>> What did you expect to happen? (Expected behavior)
>>> Expected to have the git push recommend a remote origin that matched
>>> the worktree, but it defaults to 'origin' all
>>> the time, which means I need to checkout a clean clone from the
>>> specific origin I'm making changes for so that I don't accidentally
>>> push to the default origin.
>>>
>>> What happened instead? (Actual behavior)
>>> Suggests 'origin' as the default origin - which is CORRECT for the
>>> main git branch, but I want to use worktrees to allow working against
>>> several remote origins, with the default being determined by which
>>> worktree I'm in.
>>>
>>> What's different between what you expected and what actually happened?
>>> Suggested 'origin' for the --set-default rather than allowing me to
>>> define the origin I want, for example 'wayfarer' as teh name of my own
>>> remote that I have cloned on github.  The default origin is still
>>> supposed to be 'origin' for pulls/naming, but when I push, it needs to
>>> recommend the matching origin.
>>>
>>> Anything else you want to add:
>>> This is a bit of feature request, but the reason I'm listing it as a
>>> bug is it makes it very easy to make a mistake by pushing to the wrong
>>> origin for a new branch.
>>
>> I don’t understand the expectation. git-worktree(1) just gives you a new
>> worktree to work on a branch, do a bisect, maybe a rebase and so on. I
>> expect `git remote add <remote>` to have nothing to do with the current
>> worktree that I am in. A remote ref is for the repository, not
>> per-worktree.
>>
>> If you are creating a local branch based on this so-called
>> worktree-specific remote and this branch exists on this remote (and
>> *only* on that one) then you can use `git worktree --add --guess-remote`
>> to automatically track the remote branch.
>