1

I'm in a scenario where we're taking a long time to migrate from repo server to another.

As such, I have one remote in my .git/config that reads

[remote "upstream"]
    url = ssh://my.old.url/here
    fetch = +refs/heads/*:refs/remotes/upstream/*
...
[remote "origin"]
    url = git@my.new.url/here
    fetch = +refs/heads/*:refs/remotes/origin/*

However, whenever I do git status or git push or git pull git checkout it defaults to upstream and not origin. How do I get it to default to origin for git commands?

Clarification: I"m not asking on a per branch basis, but on a project basis, so that all commands default to origin unless otherwise stated.

(Updating by git commands rather than editing the config file is preferred.)

lilHar
  • 1,735
  • 3
  • 21
  • 35
  • 1
    Does this answer your question? [Changing the Git remote 'push to' default](https://stackoverflow.com/questions/18801147/changing-the-git-remote-push-to-default) – Zois Tasoulas Feb 02 '21 at 18:12
  • 1
    This isn't a duplicate. This question is asking how to change git's default of `origin` globally, not per-branch. – Adam Millerchip Feb 03 '21 at 14:29

2 Answers2

2

git push:

Works like git push <remote>, where is the current branch’s remote (or origin, if no remote is configured for the current branch).

That is to push to origin by default you need to unset fixed remotes for all your local branches:

git for-each-ref --format="%(refname:short)" refs/heads/ |
    xargs git branch --unset-upstream

Please be advised this only works with literal origin. There is no way to make upstream the global default — you will have to configure it per-branch:

git for-each-ref --format="%(refname:short)" refs/heads/ |
    xargs git branch --set-upstream-to=upstream
phd
  • 82,685
  • 13
  • 120
  • 165
  • With everything I'm seeing about git per-branch settings focus, this is the closest to what I was asking for of a global settings change. – lilHar Feb 03 '21 at 21:42
2

I'm not asking on a per branch basis

You may not be asking on a per branch basis, but the answer is on a per branch basis.

The problem here is that git remote doesn't do what you think it does. It merely establishes a name. For example, you have configured the name upstream to mean ssh://my.old.url/here.

So now when you say, for example, git push upstream main, Git knows what upstream means.

But that has nothing to do with what happens when you say git push plain and simple. The rules for what that means are built into main itself. You can find out more about what rules are set with git branch --all -vv. That will show you each branch and how it hooks up to a corresponding remote.

By a stroke of extreme misfortune, this hookup between a local branch and the remote that it pushes to by default is called the branch's "upstream". This is one of many completely related ways in which the word "upstream" is used in Git, and has nothing to do with the use of upstream as a remote name.

So in your situation, where you've got two remotes, I would suggest that you use git push in its full form, always supplying the remote name. Arguably it might be better if git push plain and simple didn't even exist. If people always had to give push and pull commands in their full form, they might have a much better understanding of what these commands actually do.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • More than git push exists though. Git checkout is a primary example to one that is defaulting to the wrong repo. Even if it exists on origin and not on upstream, it complains about it not existing on upstream if I try to checkout a branch from origin. – lilHar Feb 02 '21 at 21:34
  • 1
    It's hard to delve deeply into all the misconceptions one might have. `git checkout` has no "default remote"; it doesn't checkout a branch from a remote at all. It checks out a _local_ branch. If you say `git checkout main` and that fails, it is because you have no local branch `main`. If you want to _create_ the local branch out of a remote-tracking branch, then as a shortcut you can say e.g. `git checkout remote/main` but then that remote-tracking branch would need to exist already, e.g. as a result of `git fetch`. `git checkout` does not do any kind of fetch/pull for you; it is purely local – matt Feb 02 '21 at 21:54
  • Does git fetch automatically only do the remote based on the branch you're currently on then? – lilHar Feb 02 '21 at 22:36
  • 1
    See 4th paragraph of Description section of docs: https://git-scm.com/docs/git-fetch Personally I usually `git fetch --all` because why not? – matt Feb 03 '21 at 00:18