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.
