Skip to content

Stop typing `git push --set-upstream`

One Git setting removes friction when publishing a branch for the first time.

Published
Reading time
2 min read
Series
Dotfiles

Early in January 2025, I made a small change to my dotfiles:

[push]
    autoSetupRemote = true

It removed a small interruption that I had accepted for far too long.

Whenever I created a local branch and pushed it for the first time, Git used to stop and tell me that the branch had no upstream. It also printed the command I was expected to run:

git push --set-upstream origin my-branch

The message was helpful. The repetition was not. Nearly every time, I wanted exactly what Git suggested: publish this branch to my normal remote under the same name, then track it.

Furthermore, it should have also suggested the configuration to adapt the default behavior, rather than the quick fix.

With push.autoSetupRemote enabled, the first plain git push does that setup automatically. Later pushes work as before. This is not an alias wrapping Git and it does not invent a new workflow. It tells Git that, when no upstream exists, my usual intent is obvious enough to act on.

Convention over configuration, configuration over repetition

I am careful about convenience settings that hide meaningful state. Remotes matter. Tracking relationships matter. A push can publish work. I still want to know which repository I am changing.

But typing --set-upstream origin was not making me reconsider any of those things. In repositories with one conventional remote, it was ceremony after the decision had already been made.

That distinction is useful beyond Git. Automate repeated mechanics, not unresolved choices. If I regularly worked with several equally plausible push remotes, I would leave this setting off. Git stopping would then protect a real decision.

In my normal repositories, there is one clear remote and matching branch names are intentional. For me, it is rather the exception to work with multiple remotes.