Re: Please discuss: what "git push" should do when you do not say what to push?

["Michael K. Johnson" <johnsonm@danlj.org>]

Thank you for the public requests for comment on changing "git push"
semantics.  I don't have anything particularly new to say, so TL;DR
is: I think that changing the default value for push.default to
upstream would help advocate corporate Git adoption as potential
users experiment on their own, attracted by the benefits of "branchy"
development.  I don't think that my own ability to advocate for Git
is affected by this decision, but wanted to share the observation.

I am encouraging corporate adoption of Git for primary source
code control, and I see two reasons for making relatively centralized
workflows easy.

It is easiest to advocate for this change when more developers are
convinced that the initial adoption process will be relatively easy;
that they can change from existing centralized version control
to Git without synchronized, protracted productivity loss due to
a steep learning curve.  Don't get me wrong, they want to make
use of DVCS concepts, and they aren't interested in the change
without expecting benefits from the change, it's just that having a
centralized workflow available makes it easier to contemplate change.
The more developers involved, the harder it would be to try to
synchronize everyone's learning curve and the more value in a
centralized workflow being available.

As has been raised several times already, most corporations are most
comfortable with having one repository that is the official main
repository, a "primus inter pares" of repositories.  At least in
my own context, for business continuity we want developers to push
topic branches to the official central repository.  In practice, very
little truly disconnected development is done; the benefits of DVCS
in general and Git in particular lie mostly in the version graph, and
secondarily in the scalability derived from repository distribution.

The default setting of push.default=matching is confusing for new
users in practice, at least in centralized workflows.  It has been
confusing in practice that they need to synchronize their master
in order to synchronize their topic branch, and in order to find
the solution they need to have some idea what solution they are
looking for -- and expect that there is a solution.

Finally, my reasoning for "upstream" instead of "current" is that
I have heard in practice that quite a few developers who are interested
in Git but not yet familiar with it have heard that branches can have
different names in different repositories, and they like the idea.
They might want to track "origin/bug1234567" in "mybug" that is
shorter and easier to remember...  This is a minor point, in my
opinion.