{"thread":{"id":"61180","subject":"Worktree shares a common remote with main checkout","startedAt":"2024-03-22T14:50:42Z","lastAt":"2024-04-03T18:29:49Z","messageCount":8,"participants":["Bill Wallace","Rubén Justo","Kristoffer Haugsbakk","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"491246","messageId":"CA+2m0i8E5Qnj520LXitoE49U_8V17v_NUnrqcRfzHz0cA_ONSQ@mail.gmail.com","threadId":"61180","inReplyTo":null,"subject":"Worktree shares a common remote with main checkout","fromName":"Bill Wallace","fromEmail":"wayfarer3130@gmail.com","sentAt":"2024-03-22T14:50:30Z","receivedAt":"2024-03-22T14:50:42Z","isPatch":false,"sender":{"key":"wayfarer3130@gmail.com","avatar":null},"body":"This issue is just to fix an easy to make mistake when working with\nmultiple remote origins and worktrees, where it is too easy to push to\nthe wrong remote origin because one can't set the default origin on a\nper-worktree basis.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\nUsed\n* git worktree to create a worktree\n* git remote add to add a custom repository\n* git commit/push to try to push changes\n\nWhat did you expect to happen? (Expected behavior)\nExpected to have the git push recommend a remote origin that matched\nthe worktree, but it defaults to 'origin' all\nthe time, which means I need to checkout a clean clone from the\nspecific origin I'm making changes for so that I don't accidentally\npush to the default origin.\n\nWhat happened instead? (Actual behavior)\nSuggests 'origin' as the default origin - which is CORRECT for the\nmain git branch, but I want to use worktrees to allow working against\nseveral remote origins, with the default being determined by which\nworktree I'm in.\n\nWhat's different between what you expected and what actually happened?\nSuggested 'origin' for the --set-default rather than allowing me to\ndefine the origin I want, for example 'wayfarer' as teh name of my own\nremote that I have cloned on github. The default origin is still\nsupposed to be 'origin' for pulls/naming, but when I push, it needs to\nrecommend the matching origin.\n\nAnything else you want to add:\nThis is a bit of feature request, but the reason I'm listing it as a\nbug is it makes it very easy to make a mistake by pushing to the wrong\norigin for a new branch.\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.31.1.windows.1\ncpu: x86_64\nbuilt from commit: c5f0be26a7e3846e3b6268d1c6c4800d838c6bbb\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Windows 10.0 22631\ncompiler info: gnuc: 10.2\nlibc info: no libc information available\n$SHELL (typically, interactive shell): \n\n\n[Enabled Hooks]\n"},{"id":"491253","messageId":"0ad0371c-c6ac-4ccb-b9a8-b30715f74308@gmail.com","threadId":"61180","inReplyTo":"CA+2m0i8E5Qnj520LXitoE49U_8V17v_NUnrqcRfzHz0cA_ONSQ@mail.gmail.com","subject":"Re: Worktree shares a common remote with main checkout","fromName":"Rubén Justo","fromEmail":"rjusto@gmail.com","sentAt":"2024-03-22T17:00:43Z","receivedAt":"2024-03-22T17:00:46Z","isPatch":false,"sender":{"key":"rjusto@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5685487?v=4"},"body":"On Fri, Mar 22, 2024 at 10:50:30AM -0400, Bill Wallace wrote:\n> This issue is just to fix an easy to make mistake when working with\n> multiple remote origins and worktrees, where it is too easy to push to\n> the wrong remote origin because one can't set the default origin on a\n> per-worktree basis.\n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> Used\n> * git worktree to create a worktree\n> * git remote add to add a custom repository\n> * git commit/push to try to push changes\n> \n> What did you expect to happen? (Expected behavior)\n> Expected to have the git push recommend a remote origin that matched\n> the worktree, but it defaults to 'origin' all\n> the time, which means I need to checkout a clean clone from the\n> specific origin I'm making changes for so that I don't accidentally\n> push to the default origin.\n\nInteresting.\n\nCan you please describe in a little more detail the new behavior?\n\nIt may be obvious, but not to me, but what should we say in these cases:\n\n - 'git [-C ] status'\n - 'git [-C ] status'\n - 'git [-C ] branch --list -v -v'\n - 'git [-C branch] --list -v -v'\n - ...\n\nI'm sure there are others that I'm missing. If you could explore and\ndescribe them, perhaps with sketches, it would be a great help.\n\nThanks.\n\n> What happened instead? (Actual behavior)\n\n> Suggests 'origin' as the default origin - which is CORRECT for the\n> main git branch, but I want to use worktrees to allow working against\n> several remote origins, with the default being determined by which\n> worktree I'm in.\n> \n> What's different between what you expected and what actually happened?\n\n> Suggested 'origin' for the --set-default rather than allowing me to\n> define the origin I want, for example 'wayfarer' as teh name of my own\n> remote that I have cloned on github. The default origin is still\n> supposed to be 'origin' for pulls/naming, but when I push, it needs to\n> recommend the matching origin.\n> \n> Anything else you want to add:\n> This is a bit of feature request, but the reason I'm listing it as a\n> bug is it makes it very easy to make a mistake by pushing to the wrong\n> origin for a new branch.\n> \n> Please review the rest of the bug report below.\n> You can delete any lines you don't wish to share.\n> \n> \n> [System Info]\n> git version:\n> git version 2.31.1.windows.1\n> cpu: x86_64\n> built from commit: c5f0be26a7e3846e3b6268d1c6c4800d838c6bbb\n> sizeof-long: 4\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> feature: fsmonitor--daemon\n> uname: Windows 10.0 22631\n> compiler info: gnuc: 10.2\n> libc info: no libc information available\n> $SHELL (typically, interactive shell): \n> \n> \n> [Enabled Hooks]\n"},{"id":"491254","messageId":"cd50671c-d3a1-4e72-89ae-e66567ee14ca@gmail.com","threadId":"61180","inReplyTo":"0ad0371c-c6ac-4ccb-b9a8-b30715f74308@gmail.com","subject":"Re: Worktree shares a common remote with main checkout","fromName":"Rubén Justo","fromEmail":"rjusto@gmail.com","sentAt":"2024-03-22T17:15:09Z","receivedAt":"2024-03-22T17:15:12Z","isPatch":false,"sender":{"key":"rjusto@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5685487?v=4"},"body":"On Fri, Mar 22, 2024 at 06:00:43PM +0100, Rubén Justo wrote:\n\n> describe them, perhaps with sketches, it would be a great help.\n\nOf course, a series would be much better received ;-)\n"},{"id":"491257","messageId":"0f65aae3-15a1-456d-8285-7923a880deea@app.fastmail.com","threadId":"61180","inReplyTo":"CA+2m0i8E5Qnj520LXitoE49U_8V17v_NUnrqcRfzHz0cA_ONSQ@mail.gmail.com","subject":"Re: Worktree shares a common remote with main checkout","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2024-03-22T17:28:44Z","receivedAt":"2024-03-22T17:29:05Z","isPatch":false,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"On Fri, Mar 22, 2024, at 15:50, Bill Wallace wrote:\n> This issue is just to fix an easy to make mistake when working with\n> multiple remote origins and worktrees, where it is too easy to push to\n> the wrong remote origin because one can't set the default origin on a\n> per-worktree basis.\n>\n> What did you do before the bug happened? (Steps to reproduce your issue)\n> Used\n> * git worktree to create a worktree\n> * git remote add to add a custom repository\n> * git commit/push to try to push changes\n>\n> What did you expect to happen? (Expected behavior)\n> Expected to have the git push recommend a remote origin that matched\n> the worktree, but it defaults to 'origin' all\n> the time, which means I need to checkout a clean clone from the\n> specific origin I'm making changes for so that I don't accidentally\n> push to the default origin.\n>\n> What happened instead? (Actual behavior)\n> Suggests 'origin' as the default origin - which is CORRECT for the\n> main git branch, but I want to use worktrees to allow working against\n> several remote origins, with the default being determined by which\n> worktree I'm in.\n>\n> What's different between what you expected and what actually happened?\n> Suggested 'origin' for the --set-default rather than allowing me to\n> define the origin I want, for example 'wayfarer' as teh name of my own\n> remote that I have cloned on github. The default origin is still\n> supposed to be 'origin' for pulls/naming, but when I push, it needs to\n> recommend the matching origin.\n>\n> Anything else you want to add:\n> This is a bit of feature request, but the reason I'm listing it as a\n> bug is it makes it very easy to make a mistake by pushing to the wrong\n> origin for a new branch.\n\nI don’t understand the expectation. git-worktree(1) just gives you a new\nworktree to work on a branch, do a bisect, maybe a rebase and so on. I\nexpect `git remote add ` to have nothing to do with the current\nworktree that I am in. A remote ref is for the repository, not\nper-worktree.\n\nIf you are creating a local branch based on this so-called\nworktree-specific remote and this branch exists on this remote (and\n*only* on that one) then you can use `git worktree --add --guess-remote`\nto automatically track the remote branch.\n"},{"id":"492161","messageId":"CA+2m0i_zGcFBd2+L_Q_foMQ=eJbXqUZGqDeOwfefg=Y4GMBRWw@mail.gmail.com","threadId":"61180","inReplyTo":"0f65aae3-15a1-456d-8285-7923a880deea@app.fastmail.com","subject":"Re: Worktree shares a common remote with main checkout","fromName":"Bill Wallace","fromEmail":"wayfarer3130@gmail.com","sentAt":"2024-04-03T14:26:34Z","receivedAt":"2024-04-03T14:26:44Z","isPatch":false,"sender":{"key":"wayfarer3130@gmail.com","avatar":null},"body":"The problem is that one wants different default remotes for different\nworktrees - for example, suppose I'm creating a worktree for two\ndifferent projects, plus the base repository is on the \"origin\"\ndefault remote. I then have:\nbase_repository - a directory with the base/default origin (call it\n'origin' for now as the remote name)\nproject1 - currently checked out with 'feat/1'\nproject2 - current checkout out with 'feat/2'\n\nNow, project1 is being developed against a remote repository\n'project1-origin' and project2 is being developed against a remote\nrepository 'project2-origin'\nHowever, both are getting merges from origin/main on their own\nprojectX-origin/main branches\n\nNow, when I'm the directory for project1 and I do any of:\n git fetch\n git checkout X\n git push\n\nI want the correct default to be chosen for the remote - for the\nbase_repository that should be 'origin', while for project1 it should\nbe 'project1-origin' etc.\nI KNOW I can specify those manually, and git push will give a\nsuggestion, but I WANT all of them to default to the correct remote\nassociated with that worktree so that I don't accidentally pick the\nwrong one or forget to update the correct repository. This is to fix\ndumb fingers that sometimes do the wrong thing without thinking, and\nto try to reduce the number of things that don't get done\naccidentally.\n\nWhat I'm doing now is to create a new non-worktree version against the\nprojects directories, but that then doesn't share any data.\n\ngit remote add ... has nothing to do with this, but I want something like:\n\ngit worktree add project1 --default-remote project1-origin\n\nThe idea is to make the expectations of what happens to be consistent\nwith cloning a new directory, or at least as close as possible to\nthat.\n\nBill.\n\nOn Fri, 22 Mar 2024 at 13:29, Kristoffer Haugsbakk wrote:\n>\n> On Fri, Mar 22, 2024, at 15:50, Bill Wallace wrote:\n> > This issue is just to fix an easy to make mistake when working with\n> > multiple remote origins and worktrees, where it is too easy to push to\n> > the wrong remote origin because one can't set the default origin on a\n> > per-worktree basis.\n> >\n> > What did you do before the bug happened? (Steps to reproduce your issue)\n> > Used\n> > * git worktree to create a worktree\n> > * git remote add to add a custom repository\n> > * git commit/push to try to push changes\n> >\n> > What did you expect to happen? (Expected behavior)\n> > Expected to have the git push recommend a remote origin that matched\n> > the worktree, but it defaults to 'origin' all\n> > the time, which means I need to checkout a clean clone from the\n> > specific origin I'm making changes for so that I don't accidentally\n> > push to the default origin.\n> >\n> > What happened instead? (Actual behavior)\n> > Suggests 'origin' as the default origin - which is CORRECT for the\n> > main git branch, but I want to use worktrees to allow working against\n> > several remote origins, with the default being determined by which\n> > worktree I'm in.\n> >\n> > What's different between what you expected and what actually happened?\n> > Suggested 'origin' for the --set-default rather than allowing me to\n> > define the origin I want, for example 'wayfarer' as teh name of my own\n> > remote that I have cloned on github. The default origin is still\n> > supposed to be 'origin' for pulls/naming, but when I push, it needs to\n> > recommend the matching origin.\n> >\n> > Anything else you want to add:\n> > This is a bit of feature request, but the reason I'm listing it as a\n> > bug is it makes it very easy to make a mistake by pushing to the wrong\n> > origin for a new branch.\n>\n> I don’t understand the expectation. git-worktree(1) just gives you a new\n> worktree to work on a branch, do a bisect, maybe a rebase and so on. I\n> expect `git remote add ` to have nothing to do with the current\n> worktree that I am in. A remote ref is for the repository, not\n> per-worktree.\n>\n> If you are creating a local branch based on this so-called\n> worktree-specific remote and this branch exists on this remote (and\n> *only* on that one) then you can use `git worktree --add --guess-remote`\n> to automatically track the remote branch.\n"},{"id":"492164","messageId":"781ba921-e11e-4c9d-8764-1366b3043375@gmail.com","threadId":"61180","inReplyTo":"CA+2m0i_zGcFBd2+L_Q_foMQ=eJbXqUZGqDeOwfefg=Y4GMBRWw@mail.gmail.com","subject":"Re: Worktree shares a common remote with main checkout","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-04-03T15:30:38Z","receivedAt":"2024-04-03T15:30:44Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Bill\n\nOn 03/04/2024 15:26, Bill Wallace wrote:\n> The problem is that one wants different default remotes for different\n> worktrees - for example, suppose I'm creating a worktree for two\n> different projects, plus the base repository is on the \"origin\"\n> default remote. I then have:\n> base_repository - a directory with the base/default origin (call it\n> 'origin' for now as the remote name)\n> project1 - currently checked out with 'feat/1'\n> project2 - current checkout out with 'feat/2'\n> \n> Now, project1 is being developed against a remote repository\n> 'project1-origin' and project2 is being developed against a remote\n> repository 'project2-origin'\n> However, both are getting merges from origin/main on their own\n> projectX-origin/main branches\n> \n> Now, when I'm the directory for project1 and I do any of:\n> git fetch\n> git checkout X\n> git push\n> \n> I want the correct default to be chosen for the remote - for the\n> base_repository that should be 'origin', while for project1 it should\n> be 'project1-origin' etc.\n\nYou can set a different default remote for \"git pull\" for each branch by \nsetting an upstream branch with \"git branch --set-upstream-to\" which \nsets \"branch..remote\" and \"branch..merge\" or \n\"branch..rebase\". You can also set a different remote to push to \nby setting \"branch..pushRemote\" - see the \"git config\" \ndocumentation. Would that help?\n\nBest Wishes\n\nPhillip\n\n> I KNOW I can specify those manually, and git push will give a\n> suggestion, but I WANT all of them to default to the correct remote\n> associated with that worktree so that I don't accidentally pick the\n> wrong one or forget to update the correct repository. This is to fix\n> dumb fingers that sometimes do the wrong thing without thinking, and\n> to try to reduce the number of things that don't get done\n> accidentally.\n> \n> What I'm doing now is to create a new non-worktree version against the\n> projects directories, but that then doesn't share any data.\n> \n> git remote add ... has nothing to do with this, but I want something like:\n> \n> git worktree add project1 --default-remote project1-origin\n> \n> The idea is to make the expectations of what happens to be consistent\n> with cloning a new directory, or at least as close as possible to\n> that.\n> \n> Bill.\n> \n> On Fri, 22 Mar 2024 at 13:29, Kristoffer Haugsbakk wrote:\n>>\n>> On Fri, Mar 22, 2024, at 15:50, Bill Wallace wrote:\n>>> This issue is just to fix an easy to make mistake when working with\n>>> multiple remote origins and worktrees, where it is too easy to push to\n>>> the wrong remote origin because one can't set the default origin on a\n>>> per-worktree basis.\n>>>\n>>> What did you do before the bug happened? (Steps to reproduce your issue)\n>>> Used\n>>> * git worktree to create a worktree\n>>> * git remote add to add a custom repository\n>>> * git commit/push to try to push changes\n>>>\n>>> What did you expect to happen? (Expected behavior)\n>>> Expected to have the git push recommend a remote origin that matched\n>>> the worktree, but it defaults to 'origin' all\n>>> the time, which means I need to checkout a clean clone from the\n>>> specific origin I'm making changes for so that I don't accidentally\n>>> push to the default origin.\n>>>\n>>> What happened instead? (Actual behavior)\n>>> Suggests 'origin' as the default origin - which is CORRECT for the\n>>> main git branch, but I want to use worktrees to allow working against\n>>> several remote origins, with the default being determined by which\n>>> worktree I'm in.\n>>>\n>>> What's different between what you expected and what actually happened?\n>>> Suggested 'origin' for the --set-default rather than allowing me to\n>>> define the origin I want, for example 'wayfarer' as teh name of my own\n>>> remote that I have cloned on github. The default origin is still\n>>> supposed to be 'origin' for pulls/naming, but when I push, it needs to\n>>> recommend the matching origin.\n>>>\n>>> Anything else you want to add:\n>>> This is a bit of feature request, but the reason I'm listing it as a\n>>> bug is it makes it very easy to make a mistake by pushing to the wrong\n>>> origin for a new branch.\n>>\n>> I don’t understand the expectation. git-worktree(1) just gives you a new\n>> worktree to work on a branch, do a bisect, maybe a rebase and so on. I\n>> expect `git remote add ` to have nothing to do with the current\n>> worktree that I am in. A remote ref is for the repository, not\n>> per-worktree.\n>>\n>> If you are creating a local branch based on this so-called\n>> worktree-specific remote and this branch exists on this remote (and\n>> *only* on that one) then you can use `git worktree --add --guess-remote`\n>> to automatically track the remote branch.\n> \n"},{"id":"492169","messageId":"CA+2m0i9JE92EqoZgNKTQn8FdY8cAxVLupa1fyRPNG_RN=5H1Cw@mail.gmail.com","threadId":"61180","inReplyTo":"781ba921-e11e-4c9d-8764-1366b3043375@gmail.com","subject":"Re: Worktree shares a common remote with main checkout","fromName":"Bill Wallace","fromEmail":"wayfarer3130@gmail.com","sentAt":"2024-04-03T16:18:11Z","receivedAt":"2024-04-03T16:18:21Z","isPatch":false,"sender":{"key":"wayfarer3130@gmail.com","avatar":null},"body":"It helps, and I do that, but I really want it associated with the\nworktree so that I can work on projects for different vendors based on\na common open source framework. What I'm trying to avoid is\naccidentally committing a branch to the wrong vendor's stream or\nmixing changes between streams.\n\nBill.\n\nOn Wed, 3 Apr 2024 at 11:30, Phillip Wood wrote:\n>\n> Hi Bill\n>\n> On 03/04/2024 15:26, Bill Wallace wrote:\n> > The problem is that one wants different default remotes for different\n> > worktrees - for example, suppose I'm creating a worktree for two\n> > different projects, plus the base repository is on the \"origin\"\n> > default remote. I then have:\n> > base_repository - a directory with the base/default origin (call it\n> > 'origin' for now as the remote name)\n> > project1 - currently checked out with 'feat/1'\n> > project2 - current checkout out with 'feat/2'\n> >\n> > Now, project1 is being developed against a remote repository\n> > 'project1-origin' and project2 is being developed against a remote\n> > repository 'project2-origin'\n> > However, both are getting merges from origin/main on their own\n> > projectX-origin/main branches\n> >\n> > Now, when I'm the directory for project1 and I do any of:\n> > git fetch\n> > git checkout X\n> > git push\n> >\n> > I want the correct default to be chosen for the remote - for the\n> > base_repository that should be 'origin', while for project1 it should\n> > be 'project1-origin' etc.\n>\n> You can set a different default remote for \"git pull\" for each branch by\n> setting an upstream branch with \"git branch --set-upstream-to\" which\n> sets \"branch..remote\" and \"branch..merge\" or\n> \"branch..rebase\". You can also set a different remote to push to\n> by setting \"branch..pushRemote\" - see the \"git config\"\n> documentation. Would that help?\n>\n> Best Wishes\n>\n> Phillip\n>\n> > I KNOW I can specify those manually, and git push will give a\n> > suggestion, but I WANT all of them to default to the correct remote\n> > associated with that worktree so that I don't accidentally pick the\n> > wrong one or forget to update the correct repository. This is to fix\n> > dumb fingers that sometimes do the wrong thing without thinking, and\n> > to try to reduce the number of things that don't get done\n> > accidentally.\n> >\n> > What I'm doing now is to create a new non-worktree version against the\n> > projects directories, but that then doesn't share any data.\n> >\n> > git remote add ... has nothing to do with this, but I want something like:\n> >\n> > git worktree add project1 --default-remote project1-origin\n> >\n> > The idea is to make the expectations of what happens to be consistent\n> > with cloning a new directory, or at least as close as possible to\n> > that.\n> >\n> > Bill.\n> >\n> > On Fri, 22 Mar 2024 at 13:29, Kristoffer Haugsbakk wrote:\n> >>\n> >> On Fri, Mar 22, 2024, at 15:50, Bill Wallace wrote:\n> >>> This issue is just to fix an easy to make mistake when working with\n> >>> multiple remote origins and worktrees, where it is too easy to push to\n> >>> the wrong remote origin because one can't set the default origin on a\n> >>> per-worktree basis.\n> >>>\n> >>> What did you do before the bug happened? (Steps to reproduce your issue)\n> >>> Used\n> >>> * git worktree to create a worktree\n> >>> * git remote add to add a custom repository\n> >>> * git commit/push to try to push changes\n> >>>\n> >>> What did you expect to happen? (Expected behavior)\n> >>> Expected to have the git push recommend a remote origin that matched\n> >>> the worktree, but it defaults to 'origin' all\n> >>> the time, which means I need to checkout a clean clone from the\n> >>> specific origin I'm making changes for so that I don't accidentally\n> >>> push to the default origin.\n> >>>\n> >>> What happened instead? (Actual behavior)\n> >>> Suggests 'origin' as the default origin - which is CORRECT for the\n> >>> main git branch, but I want to use worktrees to allow working against\n> >>> several remote origins, with the default being determined by which\n> >>> worktree I'm in.\n> >>>\n> >>> What's different between what you expected and what actually happened?\n> >>> Suggested 'origin' for the --set-default rather than allowing me to\n> >>> define the origin I want, for example 'wayfarer' as teh name of my own\n> >>> remote that I have cloned on github. The default origin is still\n> >>> supposed to be 'origin' for pulls/naming, but when I push, it needs to\n> >>> recommend the matching origin.\n> >>>\n> >>> Anything else you want to add:\n> >>> This is a bit of feature request, but the reason I'm listing it as a\n> >>> bug is it makes it very easy to make a mistake by pushing to the wrong\n> >>> origin for a new branch.\n> >>\n> >> I don’t understand the expectation. git-worktree(1) just gives you a new\n> >> worktree to work on a branch, do a bisect, maybe a rebase and so on. I\n> >> expect `git remote add ` to have nothing to do with the current\n> >> worktree that I am in. A remote ref is for the repository, not\n> >> per-worktree.\n> >>\n> >> If you are creating a local branch based on this so-called\n> >> worktree-specific remote and this branch exists on this remote (and\n> >> *only* on that one) then you can use `git worktree --add --guess-remote`\n> >> to automatically track the remote branch.\n> >\n"},{"id":"492181","messageId":"CA+2m0i_UaGsBGYt5=CDYP1q13G1m2dB47QfnQ46J7BX8yrX0-A@mail.gmail.com","threadId":"61180","inReplyTo":"17c2d5148e3afb10.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: Worktree shares a common remote with main checkout","fromName":"Bill Wallace","fromEmail":"wayfarer3130@gmail.com","sentAt":"2024-04-03T18:29:38Z","receivedAt":"2024-04-03T18:29:49Z","isPatch":false,"sender":{"key":"wayfarer3130@gmail.com","avatar":null},"body":"Each branch has a parent origin/remote repository that it is directly\ntracking (or not tracking), but there are other operations that\npresume the name \"origin\" as the name - the two that I care about are:\n\ngit fetch\n- this should be able to default fetch a remote associated with the worktree\n\ngit push (on a new branch)\nsays:\n git push --set-upstream origin testBranch\n\nI want this to say\n git push --set-upstream project1-remote testBranch\n\ninstead. Ideally, adding this automatically should set the upstream\nremote to the specified upstream branch if that is configured (which I\nnever do, since I often switch the upstream).\n\nIdeally supposing there are two branches origin/main and\nproject1-remote/main, then doing:\ngit checkout main\nin worktree project1 would checkout project1-remote/main\nwhile doing it in the original checkout would checkout origin/main\n\nThere is no change to the functionality of worktree branches, the only\nchange is the ability to store configuration values associated with a\nworktree (not a branch, but the worktree itself), plus getting the\nname \"origin\" from configuration instead of defaulting to \"origin\"\n\nThe setting `checkout.defaultRemote` is close - but I want that to be\nsomething like:\nworktree..remote=\neg\nworktree.project1.remote=project1-remote\n\nand then:\ngit fetch\nwill fetch from project1-remote when in project1 worktree\n\nWith git push having auto setup remote, this will default to pushing a\nbranch testBranch to\nproject1-remote/testBranch\nand without it being auto setup, will show the message:\n\"git push --set-upstream project1-remote testBranch\"\nas specified above.\n\ngit checkout nonLocalBranch\nwill first try to get nonLocalBranch from project1-remote, and only if\nit is ambiguous on other systems would it complain.\n\nBill\n\nOn Wed, 3 Apr 2024 at 13:24, Brian Lyles wrote:\n>\n> Hi Bill,\n>\n> Phillip Wood wrote:\n>\n> > You can set a different default remote for \"git pull\" for each branch by\n> > setting an upstream branch with \"git branch --set-upstream-to\" which\n> > sets \"branch..remote\" and \"branch..merge\" or\n> > \"branch..rebase\". You can also set a different remote to push to\n> > by setting \"branch..pushRemote\" - see the \"git config\"\n> > documentation. Would that help?\n>\n> Bill Wallace wrote:\n>\n> > It helps, and I do that, but I really want it associated with the\n> > worktree so that I can work on projects for different vendors based on\n> > a common open source framework. What I'm trying to avoid is\n> > accidentally committing a branch to the wrong vendor's stream or\n> > mixing changes between streams.\n>\n> My understanding of worktrees has always been that they are simply a\n> checkout of an arbitrary branch, and that branches themselves define\n> their remote as Phillip noted.\n>\n> I'm struggling to reconcile this fact of a branch defining its remote\n> with having a worktree also define the remote. How would this be\n> expected to behave if you try to switch a worktree with some defined\n> remote to a branch based on another remote? A warning or error?\n>\n> I am also wondering if an adjustment to your branch creation/management\n> would solve this problem without needing such a significant change to\n> the definition of a worktree.\n>\n> At the point of branch creation, the branch will track a specific remote\n> based on the ref it's created from (assuming that ref is a remote\n> tracking ref, and based on your `branch.autoSetupMerge`/whether\n> `--track`/`--no-track` is used). The remote can be corrected after\n> creation as Phillip noted.\n>\n> For example: My understanding is that if you were to set your\n> `branch.autoSetupMerge` to `inherit`, then when you create a new branch\n> it would inherit the remote tracking ref (and therefore the remote) from\n> the branch that you create it from. This would be the case whether you\n> specify a ref manually at the time of creation, or just omit it to\n> create the branch from the current checked out branch. If the latter,\n> then by creating new branches from within the worktree that you\n> designated for a specific vendor/stream, you ensure that the new branch\n> uses that same remote.\n>\n> Have you tried that approach? `branch.autoSetupMerge` has\n> several other values to control this behavior as well though `inherit`\n> seems closest to what you're looking for to me. If this is still\n> insufficient, I'd be curious to hear more specifics about where it\n> breaks down.\n>\n> --\n> Thank you,\n> Brian Lyles\n"}]}