Re: Proposal: branch.<name>.remotepush

Junio C Hamano <gitster@pobox.com> writes:

Another thing to know about is that the recent move to change the behaviour of "git push" to work only on one branch per default may have to be polished and strengthened a bit.

Originally, the encouraged workflow was to perfect _everything_ that you would push out and then with a single "git push" to publish everything at the same time. Both the "matching" behaviour of "git push" which was the default, and the set of push refspecs that is to be defined per remote, were ways to discourage "Work on one branch, think it is OK, hastily push only that branch out, switch to another branch, rinse, repeat".

To support a triangular arrangement well, there may need some thinking on what $branch@{upstream} means. The original intent of the upstream mode specified for "push.default" is push the result back to what you based your work on, but in a triangular arrangement that is no longer true. You may be keeping up with my 'master' by constantly rebasing and then pushing out the result to your 'frotz' topic. You want to have a lazy "git fetch" to fetch from my 'master' (i.e. upstream), and have remotes/origin/master to keep track of it. You want to see "git rebase" to pay attention to the updates to remotes/origin/master when figuring out where you forked. But at the same time, you want a lazy "git push" to go to your push.defaultTo repository (i.e. your publish point) and update your 'frotz' branch there---remotes/origin/master should not come into the picture at all. But the upstream and simple modes want to pay attention to branch.$name.merge, which is all about the "fetch and integrate" side of the equation.