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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html