Re: git push default behaviour?

Hi,
I consider myself a little bit experienced git newbie. I use git 1.7.5.4
I use git for 9 month in this way:
1. copy a released version from a centralized versioning control
system (this VCS does not have any git interface) to my local git repo
2. do work in git in my-branch
3. copy current work-in-progress reconfiguration from VCS to git
4. rebase my-branch onto current work-in-progress
5. copy my work to VCS
Therefore, no usage of push/pull.

I created my first public repo in which I share the released versions
of 4 development streams in 4 independent branches with my colleagues.
My usual workflow is:
1. copy a released version from VCS to my local git repo
2. git add .
3. git commit
4. git tag <release-name>
5. git push <my-public-repo> HEAD
6. git push <release-name>
I expected that push is meant (even after reading man git-push) to be
used in this way:
1. do some work in my-branch
2. merge it to master
3. git push
and this will push only the changes in the master branch I am
currently switched on.

Now, I realized that git push default is not "upstream" (the behaviour I expected) but is "matching" that brings more automation (I assume git community wants to achieve as much automation as possible).

I agree with Sebastien that current git push.default is too much automation for newbies that "upstream" would be a better default for newbies.

I came across an inconvenience in man git-push. There is no Configuration section that will inform about the push.default configuration parameter and educate the reading about various push behaviours. I know that there is man git-config but it's too long and it's too tedious to read all git configuration options.

Maybe, adding the Configuration section to man git-push will help.

Best regards, Pavel Pospisil

On Sat, Mar 17, 2012 at 10:51 AM, Sebastien Douche <sdouche@gmail.com> wrote: