From: Phillip Wood Date: Wed, 03 Apr 2024 15:30:38 GMT Subject: Re: Worktree shares a common remote with main checkout Message-ID: <781ba921-e11e-4c9d-8764-1366b3043375@gmail.com> In-Reply-To: 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..remote" and "branch..merge" or "branch..rebase". You can also set a different remote to push to by setting "branch..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 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 ` 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. >