{"thread":{"id":"29997","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","startedAt":"2012-03-19T18:26:35Z","lastAt":"2012-03-19T18:26:35Z","messageCount":1,"participants":["Michael K. Johnson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"187270","messageId":"20120319182635.GA23181@people.danlj.org","threadId":"29997","inReplyTo":null,"subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Michael K. Johnson","fromEmail":"johnsonm@danlj.org","sentAt":"2012-03-19T18:26:35Z","receivedAt":"2012-03-19T18:26:35Z","isPatch":false,"sender":{"key":"johnsonm@danlj.org","avatar":null},"body":"Thank you for the public requests for comment on changing \"git push\"\nsemantics.  I don't have anything particularly new to say, so TL;DR\nis: I think that changing the default value for push.default to\nupstream would help advocate corporate Git adoption as potential\nusers experiment on their own, attracted by the benefits of \"branchy\"\ndevelopment.  I don't think that my own ability to advocate for Git\nis affected by this decision, but wanted to share the observation.\n\nI am encouraging corporate adoption of Git for primary source\ncode control, and I see two reasons for making relatively centralized\nworkflows easy.\n\nIt is easiest to advocate for this change when more developers are\nconvinced that the initial adoption process will be relatively easy;\nthat they can change from existing centralized version control\nto Git without synchronized, protracted productivity loss due to\na steep learning curve.  Don't get me wrong, they want to make\nuse of DVCS concepts, and they aren't interested in the change\nwithout expecting benefits from the change, it's just that having a\ncentralized workflow available makes it easier to contemplate change.\nThe more developers involved, the harder it would be to try to\nsynchronize everyone's learning curve and the more value in a\ncentralized workflow being available.\n\nAs has been raised several times already, most corporations are most\ncomfortable with having one repository that is the official main\nrepository, a \"primus inter pares\" of repositories.  At least in\nmy own context, for business continuity we want developers to push\ntopic branches to the official central repository.  In practice, very\nlittle truly disconnected development is done; the benefits of DVCS\nin general and Git in particular lie mostly in the version graph, and\nsecondarily in the scalability derived from repository distribution.\n\nThe default setting of push.default=matching is confusing for new\nusers in practice, at least in centralized workflows.  It has been\nconfusing in practice that they need to synchronize their master\nin order to synchronize their topic branch, and in order to find\nthe solution they need to have some idea what solution they are\nlooking for -- and expect that there is a solution.\n\nFinally, my reasoning for \"upstream\" instead of \"current\" is that\nI have heard in practice that quite a few developers who are interested\nin Git but not yet familiar with it have heard that branches can have\ndifferent names in different repositories, and they like the idea.\nThey might want to track \"origin/bug1234567\" in \"mybug\" that is\nshorter and easier to remember...  This is a minor point, in my\nopinion.\n"}]}