CODEWITHSUNDEEP
gitbashpushgit-push
Arturo Herrero
Arturo Herrero

Reputation: 13122

What are the implications of switching to git config push.default current?

I have a Bash function to prevent the error when pushing to a remote repository (eg. GitHub) without an upstream branch. Probably you are familiar with this error:

$ git checkout -b test
$ git push
fatal: The current branch test has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin test

To fix that, what I do is intercept any calls to git push and see if I'm getting an error related to no upstream branch. In the case of that error, instead of copy and paste the suggested command above, my terminal it's going to execute it automatically for me.

This is the code if you are curious: https://github.com/arturoherrero/dotfiles/blob/6f517a0b7287ac61174dfd2b6c9ee5bf9a9c2e96/system/git.sh#L22-L34

My current Git configuration is push.default simple, but today I've just realised that I can use push.default current to achieve the same behaviour (removing my custom code).

Ref. https://www.kernel.org/pub/software/scm/git/docs/git-config.html

  • 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.

  • 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.

So, what are the implications of switching to git config push.default current? I'd like to understand some possible scenarios where I could have problems because Git has a different behaviour.

Upvotes: 0

Views: 322

Answers (1)

Mark Adelsberger
Mark Adelsberger

Reputation: 45679

The implications are that when you push to any repo, git will assume that branch names correspond. If you only ever push to a single remote (origin) and you always use the same name for the same branch in the remote and local, then it will be fine. If you want to set up other types of branch mapping - for example, if local feature branch feature_1 should go to remote branch dev/features/feature_1 or something like that - then you would not want to use simple as your push.default.

There's aren't really any hidden implications; the documentation you posted explains the behavior, and if it's the behavior you want you can use it.

Upvotes: 3

Related Questions