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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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. > >
