Worktree shares a common remote with main checkout

Worktree shares a common remote with main checkout

[Bill Wallace]

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.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.31.1.windows.1
cpu: x86_64
built from commit: c5f0be26a7e3846e3b6268d1c6c4800d838c6bbb
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 22631
compiler info: gnuc: 10.2
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>


[Enabled Hooks]

Re: Worktree shares a common remote with main checkout

[Rubén Justo]

On Fri, Mar 22, 2024 at 10:50:30AM -0400, 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.

Interesting.

Can you please describe in a little more detail the new behavior?

It may be obvious, but not to me, but what should we say in these cases:

  - 'git [-C <custom_worktree>] status'
  - 'git [-C <main-worktree>] status'
  - 'git [-C <custom_worktree>] branch --list -v -v'
  - 'git [-C <main_worktree> branch] --list -v -v'
  - ...

I'm sure there are others that I'm missing.  If you could explore and
describe them, perhaps with sketches, it would be a great help.

Thanks.

> 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.
> 
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
> 
> 
> [System Info]
> git version:
> git version 2.31.1.windows.1
> cpu: x86_64
> built from commit: c5f0be26a7e3846e3b6268d1c6c4800d838c6bbb
> sizeof-long: 4
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> uname: Windows 10.0 22631
> compiler info: gnuc: 10.2
> libc info: no libc information available
> $SHELL (typically, interactive shell): <unset>
> 
> 
> [Enabled Hooks]

Re: Worktree shares a common remote with main checkout

[Rubén Justo]

On Fri, Mar 22, 2024 at 06:00:43PM +0100, Rubén Justo wrote:

> describe them, perhaps with sketches, it would be a great help.

Of course, a series would be much better received ;-)

Re: Worktree shares a common remote with main checkout

[Kristoffer Haugsbakk]

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.

Re: Worktree shares a common remote with main checkout

[Bill Wallace]

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

Re: Worktree shares a common remote with main checkout

[Phillip Wood]

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

Re: Worktree shares a common remote with main checkout

[Bill Wallace]

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.

Bill.

On Wed, 3 Apr 2024 at 11:30, Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> 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.
> >

Re: Worktree shares a common remote with main checkout

[Bill Wallace]

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