Re: push.default???

Paolo Bonzini <paolo.bonzini@gmail.com> writes:

I actually have been having a hard time imagining how such a set-up makes sense, even during your absense (i.e. the timeframe we did push.default).

You are forking off of shared 'master', but you are developing a feature on a separate branch 'feature'.

That is a sane thing to do for two reasons. (1) Until 'feature' is done to your own satisfaction, you do not want to contaminate your own 'master' with the half-cooked feature development in it. (2) While you are working on 'feature', you may want to update your own 'master' from the shared repository to monitor how others are doing. Having a separate, pristine 'master' branch allows you to do so more easily, than detaching HEAD at 'origin/master' every once in a while.

However, when 'feature' is fully cooked, before pushing it back to be shared with others in the group, don't you do any testing with the work done by others while you were working on 'feature'? That means you first integrate your 'feature' locally into shared 'master' and make sure all fits together well.

Until you do that, you cannot be confident that the feature you developed is fit for public consumption. But if you test after merging 'feature' into 'master', what you determined as good is in 'master', which you can push back to the remote's 'master'.

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

or even worse:

	$ git checkout feature
        $ git rebase master
        $ git checkout master
        $ git merge 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. If you do a merge, that is quite straightforward:

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

but instead you have to do something like:

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

and you end up needing "put my 'feature' into their 'master'".

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.