Create a branch from an other branch without tracking it

Question

Usually, I create a branch like this:

git checkout branch
git checkout -b new_branch

It works well because it doesn't automatically set an upstream branch so it shows me the warning to push to setup the upstream. I usually copy paste it and then it tracks correctly a remote branch...

That said it's pretty cumbersome...

So I started using a new method to reduce the amount of steps:

git checkout -b new_branch from_branch

Unfortunately it gives me this output:

git checkout -b xxx origin/staging
Branch xxx set up to track remote branch staging from origin.
...

So when I try to push, it gives me this error:

fatal: The upstream branch of your current branch does not match

Obviously the upstream isn't the one I wanted... I'd rather have it automatically add origin/xxx or no upstream at all.

I see there is a "--no-track" option; is there a way to make it the default? I haven't got success using the track option.

Answer 1

As you noted, the git checkout command supports the same --track / --no-track options as git branch, so to make new branch zorblatt point to the same commit as origin/master, yet not have origin/master as its (wrong) upstream:

git checkout -b zorblatt --no-track origin/master

Unfortunately there's no way to default to that. (Curiously, there is a configuration knob for git-gui, gui.matchTrackingBranch.)

(Aside: the old verb, track, kind of sucks: "branch X tracks remote-tracking branch Y/Z" and pretty soon the words "branch" and "track" no longer seem to mean anything. "Have as upstream" is clumsy, but at least is not from the Department of Redundancy Department.)

Answer 2

tl;dr: you probably want to do git config --global push.default=upstream, but there are other settings for the exact operation a bare git push will perform that might be more congenial to your workflow.

---

Git's defaults have been an ongoing work. The operation a bare git push performed was once ... well, the C++ term for it is "expert friendly", it makes perfect sense to people who understand, but is a surprise to people still finding their legs. So then git added a push.default setting, and various "modes", ways of deciding what a bare git push would do, with the idea of finding and eventually switching to something reasonable that wouldn't lead newbies to complaining about the damage they'd just unwittingly done.

The short form is, the new factory-default behavior is effectively a child-proof cap, something you just have to learn to get past, and it stops the unwary from hurting themselves.

If you read the git push docs it alludes to all this and points you to the git config docs for push.default:

When the command line does not specify what to push with <refspec> ... arguments or --all, --mirror, --tags options, the command finds the default <refspec> by consulting remote.*.push configuration, and if it is not found, honors push.default configuration to decide what to push (See git-config for the meaning of push.default).

When neither the command-line nor the configuration specify what to push, the default behavior is used, which corresponds to the simple value for push.default: the current branch is pushed to the corresponding upstream branch, but as a safety measure, the push is aborted if the upstream branch does not have the same name as the local one.

and the other options are

push.default

Defines the action git push should take if no refspec is explicitly given. Different values are well-suited for specific workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), upstream is probably what you want. Possible values are:

• nothing - do not push anything (error out) unless a refspec is explicitly given. This is primarily meant for people who want to avoid mistakes by always being explicit.

• current - push the current branch to update a branch with the same name on the receiving end. Works in both central and non-central workflows.

• upstream - push the current branch back to the branch whose changes are usually integrated into the current branch (which is called @{upstream}). This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow).

• simple - in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch’s name is different from the local one.

  When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners.

  This mode has become the default in Git 2.0.

• matching - push all branches having the same name on both ends. This makes the repository you are pushing to remember the set of branches that will be pushed out (e.g. if you always push maint and master there and no other branches, the repository you push to will have these two branches, and your local maint and master will be pushed there).

  To use this mode effectively, you have to make sure all the branches you would push out are ready to be pushed out before running git push, as the whole point of this mode is to allow you to push all of the branches in one go. If you usually finish work on only one branch and push out the result, while other branches are unfinished, this mode is not for you. Also this mode is not suitable for pushing into a shared central repository, as other people may add new branches there, or update the tip of existing branches outside your control.

  This used to be the default, but not since Git 2.0 (simple is the new default).