Use upstream as the base branch for new pull requests

[vermiculus]

This is spawned from vermiculus/magithub#58.

I'll probably be able to change the default behavior in my development, but I think it deserves to be considered as basic hub behavior as well. To my understanding, upstream is a more appropriate default across GitHub workflows. (At the very least, I can't think of any counter-arguments.)

[mislav]

Could you elaborate a bit more? Are you talking about a git remote named "upstream", by chance? Or are you talking about git repositories that have their default branch set to "upstream" instead of "master"? Which mainstream git workflows change the name of the main branch to "upstream"? I've heard of "develop" (e.g. git-flow) but never of "upstream".

[vermiculus]

I'm not talking about any particular branch; I'm talking about a branch property (set with git branch --set-upstream my-branch my-upstream).

Consider a scenario (as in the linked issue) where a pull request is being made against a feature/ branch. This feature/ branch is the upstream of your development branch. The upstream of the feature/ branch could be master. To my understanding, 'upstream' is the basic idea of 'where is this branch going to ultimately end up?'.

[mislav]

Ah I see. Thanks for the clarification!

The workflow that you are describing makes sense. However, sometimes the upstream configuration is not the source where upstream changes are pulled from, but where the branch is going to get published to. For instance:

git push -u origin wip-feature:my-feature

This pushes the local "wip-feature" branch to a remote "my-feature" branch and sets upstream configuration for it. This makes sense where git config push.default is set to "upstream" in central workflows. In this case, it doesn't make sense that my-feature would be the base for the pull request because it is actually the head of the pull request.

I'm afraid that I can't think of ways right now that the original user's intent could be detected. There are lots of different git workflows floating around these days and I'm not sure if we can reliably detect which approach is someone using from hub.