Re: push.default???

Junio C Hamano [off-list ref] writes:

One glitch I can think of is what would happen if you do not want to merge
your feature for final testing to master, but instead rebase your feature
on top of master (let's not discuss why you should or should not rebase at
this point; some projects seem to insist you rebase and there may be no
good technical reason but that is not the topic here).  There currently is
no easy UI other than:

      $ git checkout master
      $ git pull --rebase . feature
      $ test test test
      $ git push origin master
...
to tell git to integrate your local work done in 'feature' to 'master' by
rebasing, instead of merging.

Sorry, but I screwed up.  The above rebases 'master', so it does not do
what we want to do.  The only way I can think of is:

or even worse:

      $ git checkout feature
      $ git rebase master
      $ git checkout master
      $ git merge feature
      $ test test test
      $ git push origin master

which is too much typing.  That makes my suspicion that the conclusion of
my previous message is correct even stronger.

Could it be possible that this desire to push "tracking" is not a cure for
anything real, but merely a kludge to work around a misfeature of "rebase"
UI that does not allow "integrate that branch here but do not merge it but
by first rebasing it"?  In other words, if we had "git merge --rebase" (I
know, I know, it is a terrible name.  The word "merge" in this context
means "to integrate"), the above can be done more naturally:

      $ git checkout master
      $ git merge --rebase feature
      $ test test test
      $ git push origin master

and the matching push (or "git push origin HEAD") becomes the right thing
to do, eliminating the need for "put my 'feature' into their 'master'".

For a group that sets up a shared public branch to be used for working
together on some feature, replace 'master' with 'some feature' above, and
'feature' with 'your part of the work on the feature'; the story is the
same.