"simple" vs "current" push.default in git for decentralized workflow

Question

Functionally speaking, in a decentralized workflow, I don't see the difference between simple and current options for push.default config setting.

current will push the current branch to an identically named branch on the specified remote. simple will effectively do the same thing as well for both the tracked and any untracked remotes for the current branch (it enforces identical branch names in both cases).

Can someone explain any important differences between the two for decentralized workflows that I am missing?

Guibert

possible duplicate of Warning: push.default is unset; its implicit value is changing in Git 2.0 – Subaxillary

@Trevor - that isn't related at all to my question. – Guibert

Answer 1

The difference is that with simple, git push (without passing a refspec) will fail if the current branch isn't tracking a remote upstream branch (even if a branch with the same name exists on the remote):

$ git checkout -b foo
Switched to a new branch 'foo'

$ git config push.default simple
$ git push
fatal: The current branch foo has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin foo

On the other hand, current doesn't care about whether or not the current branch tracks an upstream, it just wants to push to any branch that has the same name:

$ git config push.default current
$ git push
Total 0 (delta 0), reused 0 (delta 0)
To /Documents/GitHub/bare
 * [new branch]      foo-> foo

The Documentation

From the Git configuration documentation:

• upstream - push the current branch to its upstream branch...

• simple - like upstream, but refuses to push if the upstream branch’s name is different from the local one...

• current - push the current branch to a branch of the same name.

Estrange

I guess the only "bonus" question is "why". I guess forcing an upstream tracking branch eliminates mistakes (accidentally overwriting that branch on the wrong remote). – Guibert

Simple seems the safer "seat belt" option. – Chellman

Revisiting my own question after a long time :-) How did current know which remote to choose? If you don't have a tracking branch set, where does it push to? – Guibert

It pushes to the default remote -> that means origin. From man git-push: When the command line does not specify where to push with the <repository> argument, branch.*.remote configuration for the current branch is consulted to determine where to push. If the configuration is missing, it defaults to origin. – Chanell

I've always used 'current' for years with absolutely no issues. For most cases it works: pulling/pushing to one repo, making new branches or checking out existing branches where naming conflicts are unlikely. Just works, no issues. Can't say it should be the default (since it's unsafe) but thank goodness it exists. – Mahon

We use "current", because we have an upstream branch set to be a shared branch, and checked out branch is a developer-specific branch that is essentially "write-only" on the server. That is, we pull from the shared branch, and push into the developer-specific branch; there's normally not a need to pull from the developer-specific branch. That allows use to just use "git pull" and "git push", without decoration, which is simplest for our developers. – Kalk

Answer 2

The difference is that simple pushes to its tracking branch if it has the same name, while current will push to a branch of the same name regardless of any tracking branch:

$ git branch -vvv
  master 58d9fdc [origin/master: ahead 1] t1 bobo
* new    37132d3 [origin/save: ahead 1] t1 bibi   # <- tracking branch 'save'

$ git -c push.default=current push                # <- set `push.default=current`
Counting objects: 3, done.
Writing objects: 100% (3/3), 234 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /home/jthill/sandbox/20/t1
 * [new branch]      new -> new                   # <- and push creates `new` 

Larina