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.
