Re: Worktree shares a common remote with main checkout

[Bill Wallace <wayfarer3130@gmail.com>]

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.