{"thread":{"id":"29881","subject":"git push default behaviour?","startedAt":"2012-03-08T10:01:46Z","lastAt":"2012-03-19T16:12:21Z","messageCount":116,"participants":["Jeremy Morton","Thomas Rast","Carlos Martín Nieto","Jakub Narebski","Matthieu Moy","demerphq","Marc Branchaud","Dmitry Potapov","Junio C Hamano","Andreas Krey","Jeff King","Ævar Arnfjörð Bjarmason","Stefan Haller","Michael Haggerty","Holger Hellmuth","Andreas Ericsson","Clemens Buchacher","Gelonida N","Sebastien Douche","Eric Hanchrow","Pavel Pospíšil","Miles Bader","Philippe Vaucher","Andrew Myers"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"186401","messageId":"CAFsnPqp1+jX3ZY0LZ1QDmvA=2_ebApPBttwFjr36OuTX2_MHug@mail.gmail.com","threadId":"29881","inReplyTo":null,"subject":"git push default behaviour?","fromName":"Jeremy Morton","fromEmail":"jeremy@configit.com","sentAt":"2012-03-08T10:01:46Z","receivedAt":"2012-03-08T10:01:46Z","isPatch":false,"sender":{"key":"jeremy@configit.com","avatar":null},"body":"Hi everyone,\n\nI've noticed that the default behaviour of 'git push' is to push to\n*all* branches that have a remote branch set up.  In order to push\njust to one branch, you must specify 'git push repo branchname'.\n\nThis seems rather unintuative to me, and in the case of a '--force',\nalmost certainly not what you want.  You're usually working on one\nbranch and just want to push that one, and it's usually the branch\nyou're currently on. And in the case of a '--force', in addition by\npushing all branches to remote, you are going to undo any changes on\nother branches made since you updated them on your local repo.\n\nWouldn't it be better for git's default push behaviour (at least with\nthe '--force' option) to be just to push to the current branch in the\ncurrent repo?  To push to all branches you could have an\n'--allbranches' option.\n\nBest regards,\nJeremy Morton (Jez)\n"},{"id":"186402","messageId":"87k42vs8pi.fsf@thomas.inf.ethz.ch","threadId":"29881","inReplyTo":"CAFsnPqp1+jX3ZY0LZ1QDmvA=2_ebApPBttwFjr36OuTX2_MHug@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2012-03-08T10:11:53Z","receivedAt":"2012-03-08T10:11:53Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeremy Morton writes:\n\n> I've noticed that the default behaviour of 'git push' is to push to\n> *all* branches that have a remote branch set up.\n[...]\n> Wouldn't it be better for git's default push behaviour (at least with\n> the '--force' option) to be just to push to the current branch in the\n> current repo?  To push to all branches you could have an\n> '--allbranches' option.\n\nSee push.default in git-config(1).\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"186403","messageId":"CAFsnPqopZEZeeuFzK4ZoUjGnfpiv5oMs=xV5XBSgSyGLXOwgqA@mail.gmail.com","threadId":"29881","inReplyTo":"87k42vs8pi.fsf@thomas.inf.ethz.ch","subject":"Re: git push default behaviour?","fromName":"Jeremy Morton","fromEmail":"jeremy@configit.com","sentAt":"2012-03-08T10:13:41Z","receivedAt":"2012-03-08T10:13:41Z","isPatch":false,"sender":{"key":"jeremy@configit.com","avatar":null},"body":"Right, so I guess I'm saying that the default value for push.default\nshould be upstream instead of matching...\n\nBest regards,\nJeremy Morton (Jez)\n\nOn Thu, Mar 8, 2012 at 10:11 AM, Thomas Rast wrote:\n> Jeremy Morton writes:\n>\n>> I've noticed that the default behaviour of 'git push' is to push to\n>> *all* branches that have a remote branch set up.\n> [...]\n>> Wouldn't it be better for git's default push behaviour (at least with\n>> the '--force' option) to be just to push to the current branch in the\n>> current repo?  To push to all branches you could have an\n>> '--allbranches' option.\n>\n> See push.default in git-config(1).\n>\n> --\n> Thomas Rast\n> trast@{inf,student}.ethz.ch\n"},{"id":"186405","messageId":"1331202483.21444.11.camel@beez.lab.cmartin.tk","threadId":"29881","inReplyTo":"CAFsnPqopZEZeeuFzK4ZoUjGnfpiv5oMs=xV5XBSgSyGLXOwgqA@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-03-08T10:28:03Z","receivedAt":"2012-03-08T10:28:03Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:\n> Right, so I guess I'm saying that the default value for push.default\n> should be upstream instead of matching...\n\nAny default is going to leave some people unhappy. If upstream is the\nright thing for you, then that's what you should use. Most questions I\nsee about push not doing what the users expect would actually benefit\nfrom 'current'. 'matching' is a fairly safe default, as it won't try to\npush private branches or changes in private branches that track\nsomething upstream.\n\n cmn\n\n\n"},{"id":"186407","messageId":"CAFsnPqpnH2CTki8zz6Mpz=qrdxF_aTA92cPrn1L9MQZVMoxdeg@mail.gmail.com","threadId":"29881","inReplyTo":"1331202483.21444.11.camel@beez.lab.cmartin.tk","subject":"Re: git push default behaviour?","fromName":"Jeremy Morton","fromEmail":"jeremy@configit.com","sentAt":"2012-03-08T10:38:15Z","receivedAt":"2012-03-08T10:38:15Z","isPatch":false,"sender":{"key":"jeremy@configit.com","avatar":null},"body":"But 'push --force' WILL try to push your (probably outdated) master\nupstream, killing any changes there made since you last updated. That\nalone is so dangerous it seems like reason enough to avoid it by\ndefault.\n\nBest regards,\nJeremy Morton (Jez)\n\nOn Thu, Mar 8, 2012 at 10:28 AM, Carlos Martín Nieto wrote:\n> On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:\n>> Right, so I guess I'm saying that the default value for push.default\n>> should be upstream instead of matching...\n>\n> Any default is going to leave some people unhappy. If upstream is the\n> right thing for you, then that's what you should use. Most questions I\n> see about push not doing what the users expect would actually benefit\n> from 'current'. 'matching' is a fairly safe default, as it won't try to\n> push private branches or changes in private branches that track\n> something upstream.\n>\n>   cmn\n>\n>\n"},{"id":"186408","messageId":"1331203321.21444.13.camel@beez.lab.cmartin.tk","threadId":"29881","inReplyTo":"CAFsnPqpnH2CTki8zz6Mpz=qrdxF_aTA92cPrn1L9MQZVMoxdeg@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-03-08T10:42:01Z","receivedAt":"2012-03-08T10:42:01Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Thu, 2012-03-08 at 10:38 +0000, Jeremy Morton wrote:\n> But 'push --force' WILL try to push your (probably outdated) master\n> upstream, killing any changes there made since you last updated. That\n> alone is so dangerous it seems like reason enough to avoid it by\n> default.\n\nThen don't use --force without specifying exactly what you want.\nAnything with that option needs to be used carefully.\n\n cmn\n"},{"id":"186412","messageId":"CAFsnPqpoBLHoshgv0MsUUStA3Q=niM8hP9yaHr+rSQvh-JWHZA@mail.gmail.com","threadId":"29881","inReplyTo":"1331203321.21444.13.camel@beez.lab.cmartin.tk","subject":"Re: git push default behaviour?","fromName":"Jeremy Morton","fromEmail":"jeremy@configit.com","sentAt":"2012-03-08T10:43:12Z","receivedAt":"2012-03-08T10:43:12Z","isPatch":false,"sender":{"key":"jeremy@configit.com","avatar":null},"body":"Obviously - but my point is that it needn't be so dangerous by\ndefault. It tries to push all matching branches - is that really a\nmore common requirement than pushing the current branch?\n\nBest regards,\nJeremy Morton (Jez)\n\nOn Thu, Mar 8, 2012 at 10:42 AM, Carlos Martín Nieto wrote:\n> On Thu, 2012-03-08 at 10:38 +0000, Jeremy Morton wrote:\n>> But 'push --force' WILL try to push your (probably outdated) master\n>> upstream, killing any changes there made since you last updated.  That\n>> alone is so dangerous it seems like reason enough to avoid it by\n>> default.\n>\n> Then don't use --force without specifying exactly what you want.\n> Anything with that option needs to be used carefully.\n>\n>   cmn\n>\n>\n"},{"id":"186416","messageId":"m3sjhjs4z5.fsf@localhost.localdomain","threadId":"29881","inReplyTo":"CAFsnPqpnH2CTki8zz6Mpz=qrdxF_aTA92cPrn1L9MQZVMoxdeg@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-08T11:33:43Z","receivedAt":"2012-03-08T11:33:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeremy Morton writes:\n> On Thu, Mar 8, 2012 at 10:28 AM, Carlos Martín Nieto wrote:\n> > On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:\n\n> >> Right, so I guess I'm saying that the default value for push.default\n> >> should be upstream instead of matching...\n> >\n> > Any default is going to leave some people unhappy. If upstream is the\n> > right thing for you, then that's what you should use. Most questions I\n> > see about push not doing what the users expect would actually benefit\n> > from 'current'. 'matching' is a fairly safe default, as it won't try to\n> > push private branches or changes in private branches that track\n> > something upstream.\n>\n> But 'push --force' WILL try to push your (probably outdated) master\n> upstream, killing any changes there made since you last updated. That\n> alone is so dangerous it seems like reason enough to avoid it by\n> default.\n\nYou can always configure server to refuse forced pushes.\n-- \nJakub Narebski\n"},{"id":"186417","messageId":"CAFsnPqqJt13gDp2RNiEU4dt59iMwFvMzysfk51mO8aF+_nYGXA@mail.gmail.com","threadId":"29881","inReplyTo":"m3sjhjs4z5.fsf@localhost.localdomain","subject":"Re: git push default behaviour?","fromName":"Jeremy Morton","fromEmail":"jeremy@configit.com","sentAt":"2012-03-08T11:34:51Z","receivedAt":"2012-03-08T11:34:51Z","isPatch":false,"sender":{"key":"jeremy@configit.com","avatar":null},"body":"On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski wrote:\n> You can always configure server to refuse forced pushes.\n\nWe're using github, and as far as I'm aware, there's no way to\nconfigure github to do that.\n\nBest regards,\nJeremy Morton (Jez)\n"},{"id":"186423","messageId":"vpqeht3qpev.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"1331202483.21444.11.camel@beez.lab.cmartin.tk","subject":"Re: git push default behaviour?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-08T11:54:00Z","receivedAt":"2012-03-08T11:54:00Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Carlos Martín Nieto writes:\n\n> On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:\n>> Right, so I guess I'm saying that the default value for push.default\n>> should be upstream instead of matching...\n>\n> Any default is going to leave some people unhappy. If upstream is the\n> right thing for you, then that's what you should use. Most questions I\n> see about push not doing what the users expect would actually benefit\n> from 'current'. 'matching' is a fairly safe default, as it won't try to\n> push private branches or changes in private branches that track\n> something upstream.\n\nThere were some discussions about changing the default, and I thought\npeople agreed that 'upstream' was a better default value for\npush.default:\n\n http://permalink.gmane.org/gmane.comp.version-control.git/167149\n\nit needs to be done with a sane migration path, however, and I guess no\none stepped in to start the process (but I may have missed some further\ndiscussions).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186429","messageId":"CANgJU+V-nSRwz7YitsDLsUA=5nm5S6L59pUhw4x50kKojLBFuA@mail.gmail.com","threadId":"29881","inReplyTo":"vpqeht3qpev.fsf@bauges.imag.fr","subject":"Re: git push default behaviour?","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-03-08T12:12:48Z","receivedAt":"2012-03-08T12:12:48Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 8 March 2012 12:54, Matthieu Moy wrote:\n> Carlos Martín Nieto writes:\n>\n>> On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:\n>>> Right, so I guess I'm saying that the default value for push.default\n>>> should be upstream instead of matching...\n>>\n>> Any default is going to leave some people unhappy. If upstream is the\n>> right thing for you, then that's what you should use. Most questions I\n>> see about push not doing what the users expect would actually benefit\n>> from 'current'. 'matching' is a fairly safe default, as it won't try to\n>> push private branches or changes in private branches that track\n>> something upstream.\n>\n> There were some discussions about changing the default, and I thought\n> people agreed that 'upstream' was a better default value for\n> push.default:\n>\n>  http://permalink.gmane.org/gmane.comp.version-control.git/167149\n>\n> it needs to be done with a sane migration path, however, and I guess no\n> one stepped in to start the process (but I may have missed some further\n> discussions).\n\nFrom the point of view of new users the current default is sub-optimal\nand confusing. I actually find the current default an odd choice, as I\npersonally have *never* wanted to push all the branches at once, nor\nhave I ever seen a colleague want to do that.\n\ncheers,\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"186453","messageId":"4F58C977.8000400@xiplink.com","threadId":"29881","inReplyTo":"1331203321.21444.13.camel@beez.lab.cmartin.tk","subject":"Re: git push default behaviour?","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-03-08T15:00:07Z","receivedAt":"2012-03-08T15:00:07Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-03-08 05:42 AM, Carlos Martín Nieto wrote:\n> On Thu, 2012-03-08 at 10:38 +0000, Jeremy Morton wrote:\n>> But 'push --force' WILL try to push your (probably outdated) master\n>> upstream, killing any changes there made since you last updated. That\n>> alone is so dangerous it seems like reason enough to avoid it by\n>> default.\n>\n> Then don't use --force without specifying exactly what you want.\n> Anything with that option needs to be used carefully.\n\nI agree with Jeremy that the default is dangerous, or at the very least \nsurprising.\n\nPerhaps --force should be changed to require an explicit ref if \npush.default = matching (and the code finds that it needs to use \npush.default's value)?\n\nBy itself that change would make it impossible to use --force to \nforce-change all matching refs (i.e. the current default behaviour would \ndisappear completely). I'm OK with that, personally.\n\n\t\tM.\n"},{"id":"186455","messageId":"vpq62efjeqd.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"4F58C977.8000400@xiplink.com","subject":"Re: git push default behaviour?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-08T15:26:34Z","receivedAt":"2012-03-08T15:26:34Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Marc Branchaud writes:\n\n> I agree with Jeremy that the default is dangerous, or at the very\n> least surprising.\n\nYes, --force is not the only problem. Getting constant non-fast forward\nerrors just because you have out-of-date local ref is annoying, and\nreally, really confusing.\n\n'push.default = matching' is never a good idea if you use shared\nrepository actually. It makes sense for people like Junio pushing a\nlocal repository to a public one, which is read-only for the rest of the\nworld. But my experience is that people using such workflow are advanced\nusers, and would know how to configure Git, so it wouldn't really harm\nthem to change the default.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186467","messageId":"CAHkcothno3tQG0G-5Mo7vVbKxUkNGqWd+6BRWhjnKafrSp1FTw@mail.gmail.com","threadId":"29881","inReplyTo":"4F58C977.8000400@xiplink.com","subject":"Re: git push default behaviour?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2012-03-08T17:37:16Z","receivedAt":"2012-03-08T17:37:16Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Mar 8, 2012 at 7:00 PM, Marc Branchaud wrote:\n>\n> Perhaps --force should be changed to require an explicit ref if push.default\n> = matching (and the code finds that it needs to use push.default's value)?\n\nNo, it will workflow for some people. In general, --force should not be\nused, but when it is used, it is used for a reason. If you need another\nbehavior like forcing only the current branch then you probably should add\n--force-current or something like that, but not to break what works now.\n\nDmitry\n"},{"id":"186471","messageId":"CAHkcotiOGaOdDvibpoiEgys3PnSPfSw0mT3DeEOix+FuboULiA@mail.gmail.com","threadId":"29881","inReplyTo":"vpq62efjeqd.fsf@bauges.imag.fr","subject":"Re: git push default behaviour?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2012-03-08T17:49:39Z","receivedAt":"2012-03-08T17:49:39Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Mar 8, 2012 at 7:26 PM, Matthieu Moy\n wrote:\n>\n> 'push.default = matching' is never a good idea if you use shared\n> repository actually. It makes sense for people like Junio pushing a\n> local repository to a public one, which is read-only for the rest of the\n> world. But my experience is that people using such workflow are advanced\n> users, and would know how to configure Git, so it wouldn't really harm\n> them to change the default.\n\nThere are more people that you think who rely on the current behavior\nof git push. For instance, pushing changes between different computers\nfor testing purposes before publishing them. When you silently change\nthe default value of push, you silently break their workflow. It is not\ndifficult to add 'push.default = matching' but you need to know that the\ndefault value has changed, so you have to add this line to preserve the\nold behavior.\n\nDmitry\n"},{"id":"186472","messageId":"vpqfwdjas0m.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"CAHkcotiOGaOdDvibpoiEgys3PnSPfSw0mT3DeEOix+FuboULiA@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-08T18:04:25Z","receivedAt":"2012-03-08T18:04:25Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Dmitry Potapov writes:\n\n> When you silently change\n> the default value of push, you silently break their workflow.\n\nNo one talked about changing it silently. Quoting myself:\n\n| it needs to be done with a sane migration path, however\n\nThere is already a configuration variable, so it's easy to fix a default\nvalue change if you rely on it, but the first thing to do is to\nencourage people to explicitely set push.default, so that they are not\naffected by a potential future default change.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186474","messageId":"7vlinbdkb0.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"CAFsnPqpoBLHoshgv0MsUUStA3Q=niM8hP9yaHr+rSQvh-JWHZA@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-08T18:22:43Z","receivedAt":"2012-03-08T18:22:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeremy Morton writes:\n\n> Obviously - but my point is that it needn't be so dangerous by\n> default. It tries to push all matching branches - is that really a\n> more common requirement than pushing the current branch?\n\nDepends on the way you work. If you publish to your own repository\nand let others pull, the behaviour is not dangerous at all with or\nwithout --force (well, --force brings its own danger but that does\nnot have anything to do with which branches are pushed). If you\ndefault to 'current' in such a workflow, you risk forgetting to\npush, which is the more dangerous option between the two.\n\nWhen using a single shared central repository to work with others,\ncurrent may be more appropriate, and that is why the behaviour is\nconfigurable.\n"},{"id":"186475","messageId":"vpq1up3aqk8.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"7vlinbdkb0.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-08T18:35:51Z","receivedAt":"2012-03-08T18:35:51Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> If you publish to your own repository\n> and let others pull, the behaviour is not dangerous at all with or\n> without --force (well, --force brings its own danger but that does\n> not have anything to do with which branches are pushed). If you\n> default to 'current' in such a workflow, you risk forgetting to\n> push, which is the more dangerous option between the two.\n\nForgetting to push a branch is a danger, but far less dangerous than\nwhat \"push --force\" can do in a shared repository.\n\nIn a shared repository, there's actually a race condition that you\ncannot avoid AFAICT:\n\n$ git push\n # get an error about non-fast-forward on branch A, but no other.\n # thing \"it's OK, I do want to do a forced update on A\".\n$ git push --force\n\nIf someone else did a push between my first push and the \"push --force\",\nthen the other user's push is discarded.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186483","messageId":"20120308190310.GA13486@inner.h.iocl.org","threadId":"29881","inReplyTo":"vpq1up3aqk8.fsf@bauges.imag.fr","subject":"Re: git push default behaviour?","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2012-03-08T19:03:10Z","receivedAt":"2012-03-08T19:03:10Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Thu, 08 Mar 2012 19:35:51 +0000, Matthieu Moy wrote:\n...\n> If someone else did a push between my first push and the \"push --force\",\n> then the other user's push is discarded.\n\nA push --semiforce would help here: Should check whether the remote\nbranch is at the same commit as origin/master locally, and only then set\nto new local master. (Would probably require protocol change to actuall\nbe atomic.)\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"186481","messageId":"7vty1ydh7p.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"vpq1up3aqk8.fsf@bauges.imag.fr","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-08T19:29:30Z","receivedAt":"2012-03-08T19:29:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> If you publish to your own repository\n>> and let others pull, the behaviour is not dangerous at all with or\n>> without --force (well, --force brings its own danger but that does\n>> not have anything to do with which branches are pushed). If you\n>> default to 'current' in such a workflow, you risk forgetting to\n>> push, which is the more dangerous option between the two.\n>\n> Forgetting to push a branch is a danger, but far less dangerous than\n> what \"push --force\" can do in a shared repository.\n>\n> In a shared repository, there's actually a race condition that you\n> cannot avoid AFAICT:\n> ...\n> If someone else did a push between my first push and the \"push --force\",\n> then the other user's push is discarded.\n\nThat is exactly what I said in the parentheses above, isn't it? The\ndanger of \"--force\" does not have anything to do with which branches\nare pushed. It comes primarily from the use of shared repository.\nThe first advice Carlos gave us in this thread, which was perfectly\nsane, applies to your observation: before you \"push --force\", think\ntwice.\n\nThat does not change the conclusion that current is more suitable\nfor shared repository workflow and matching is more (not \"equally to\ncurrent\") suitable for publishing repository workflow, and we have a\nway for user to tell Git which one is being used in a particular\nproject exactly for that purpose.\n"},{"id":"186519","messageId":"20120309033826.GA6164@sigill.intra.peff.net","threadId":"29881","inReplyTo":"vpqfwdjas0m.fsf@bauges.imag.fr","subject":"Re: git push default behaviour?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-09T03:38:27Z","receivedAt":"2012-03-09T03:38:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 08, 2012 at 07:04:25PM +0100, Matthieu Moy wrote:\n\n> Dmitry Potapov writes:\n> \n> > When you silently change\n> > the default value of push, you silently break their workflow.\n> \n> No one talked about changing it silently. Quoting myself:\n> \n> | it needs to be done with a sane migration path, however\n> \n> There is already a configuration variable, so it's easy to fix a default\n> value change if you rely on it, but the first thing to do is to\n> encourage people to explicitely set push.default, so that they are not\n> affected by a potential future default change.\n\nThis is all sounding eerily familiar. Indeed:\n\n $ git log --oneline -Swarn_unconfigured_push -- builtin-push.c\n bba0fd2 push: do not give big warning when no preference is configured\n 665d3e8 Display warning for default git push with no push.default config\n\nI don't remember the mailing list conversations that surrounded those\npatches, but if we are going to have the same conversation again, maybe\nit is worth looking them up.\n\n-Peff\n"},{"id":"186523","messageId":"7vsjhi9wku.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"20120309033826.GA6164@sigill.intra.peff.net","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T05:23:29Z","receivedAt":"2012-03-09T05:23:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> This is all sounding eerily familiar. Indeed:\n>\n> $ git log --oneline -Swarn_unconfigured_push -- builtin-push.c\n> bba0fd2 push: do not give big warning when no preference is configured\n> 665d3e8 Display warning for default git push with no push.default config\n>\n> I don't remember the mailing list conversations that surrounded those\n> patches, but if we are going to have the same conversation again, maybe\n> it is worth looking them up.\n\nI just dug it up; start from here:\n\n http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541\n\nread on a few messages downthread, and then jump to the other thread\nNana points at in the above message.\n\nIn short, we started warning that we _might_ change the default\nsomeday, without having a clear concensus or plan, that ended up\nconfusing and annoying users without giving them anything good,\nother than awareness that such a feature is _available_.\n\nSo no, the conversation did not decide if changing the default was\nwarranted or not. It just confirmed that we weren't anywhere close\nto deciding back then.\n"},{"id":"186524","messageId":"7vobs69vwj.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"7vsjhi9wku.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T05:38:04Z","receivedAt":"2012-03-09T05:38:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I just dug it up; start from here:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541\n>\n> read on a few messages downthread, and then jump to the other thread\n> Nana points at in the above message.\n>\n> In short, we started warning that we _might_ change the default\n> someday, without having a clear concensus or plan, that ended up\n> confusing and annoying users without giving them anything good,\n> other than awareness that such a feature is _available_.\n>\n> So no, the conversation did not decide if changing the default was\n> warranted or not. It just confirmed that we weren't anywhere close\n> to deciding back then.\n\nI think MJG's message (the second on in the \"git push origin error\"\nthread) is probably what we would need to repeat, and this time more\nstrongly to squelch the opposition from old timers, if somebody\nwants to resurrect the \"warn until you set the default explicitly,\nintending to change the default in the future\" patch. And this time\naround, the plan to change the default should be more concrete with\nspecific date, e.g. \"Starting from April 1st, 2013\".\n\nI was in the \"keep the default to matching, so that nobody among\nexisting 47 million users would be annoyed\" camp (back then we\nprobably didn't have 47 million users, but that is besides the\npoint) and I still am, but notice that I was defending the argument\nby the \"let's be ( (new user) friendly )\" camp in that thread. And\nwithout much fire-support from those who were vocal about it.\n\nRe-reading the thread made me sick.\n\nI wish I had enough energy remaining to say \"Let's try one more\ntime, and hope that people from the 'let's change the default' camp\nwill behave much better than the last time\", but I do not have high\nhopes, after having been burned once already with exactly the same\nissue.\n"},{"id":"186535","messageId":"vpqr4x26vyp.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"7vty1ydh7p.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-09T08:05:02Z","receivedAt":"2012-03-09T08:05:02Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> That is exactly what I said in the parentheses above, isn't it? The\n> danger of \"--force\" does not have anything to do with which branches\n> are pushed.\n\nI disagree. A user may use --force because he has good reason to think\nthat a branch hasn't been been touched by others, but it's much harder\nto guarantee that all branches haven't been touched.\n\n> That does not change the conclusion that current is more suitable\n> for shared repository workflow and matching is more (not \"equally to\n> current\") suitable for publishing repository workflow, and we have a\n> way for user to tell Git which one is being used in a particular\n> project exactly for that purpose.\n\nWe're not talking about the same thing. You're talking about how\n_appropriate_ a value is, and I'm mentionning how _dangerous_ it can be.\n\nAnd regardless of the danger, if I look around me, I see almost only\npeople working with shared archives, and a few projects (including Git,\nobviously) using the \"one commiter per repository\" workflow (I teach Git\nto 200 students and several colleagues every year, I've tried teaching\nthe \"one public repository per developer\" and it was a complete disaster).\n\nI really think the default should help these people.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186536","messageId":"CANgJU+WMxnNgdsP4JV6aAVW07NeWXUa5LsEa4dk5_1CZXC1nXA@mail.gmail.com","threadId":"29881","inReplyTo":"7vobs69vwj.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-03-09T08:06:18Z","receivedAt":"2012-03-09T08:06:18Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 9 March 2012 06:38, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> I just dug it up; start from here:\n>>\n>>     http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541\n>>\n>> read on a few messages downthread, and then jump to the other thread\n>> Nana points at in the above message.\n>>\n>> In short, we started warning that we _might_ change the default\n>> someday, without having a clear concensus or plan, that ended up\n>> confusing and annoying users without giving them anything good,\n>> other than awareness that such a feature is _available_.\n>>\n>> So no, the conversation did not decide if changing the default was\n>> warranted or not. It just confirmed that we weren't anywhere close\n>> to deciding back then.\n>\n> I think MJG's message (the second on in the \"git push origin error\"\n> thread) is probably what we would need to repeat, and this time more\n> strongly to squelch the opposition from old timers, if somebody\n> wants to resurrect the \"warn until you set the default explicitly,\n> intending to change the default in the future\" patch. And this time\n> around, the plan to change the default should be more concrete with\n> specific date, e.g. \"Starting from April 1st, 2013\".\n>\n> I was in the \"keep the default to matching, so that nobody among\n> existing 47 million users would be annoyed\" camp (back then we\n> probably didn't have 47 million users, but that is besides the\n> point) and I still am, but notice that I was defending the argument\n> by the \"let's be ( (new user) friendly )\" camp in that thread. And\n> without much fire-support from those who were vocal about it.\n>\n> Re-reading the thread made me sick.\n>\n> I wish I had enough energy remaining to say \"Let's try one more\n> time, and hope that people from the 'let's change the default' camp\n> will behave much better than the last time\", but I do not have high\n> hopes, after having been burned once already with exactly the same\n> issue.\n\nI think I read all the relevant mails, and I have a thought concerning\nwhat I see to be the class of the problem here: the general question\nof \"how do you change default behavior if it turns out that the\noriginal choice was inappropriate\". It seems to me you can think of\nsolutions to that problem in general without considering the subject\nof this thread.\n\nA possible solution might be to give config files a \"format version\"\nof their own. They already contain a repository format version number,\nso add a new variable \"ConfigVersionLevel\". Alongside that you might\nintroduce a policy of having new git \"fill in\" the defaults missing\nfrom the config file whenever it operates, so that people can\nexplicitly view then all at once. Then if the defaults change in the\nfuture an old repo will continue to work as it did before. This alone\nwould allow you to change the defaults for existing configurable\nbehavior, but you need the version number to handle new options.\n\nOnce you have that you can change the default behavior based on the\nversion level so that older users operating in older repositories get\nthe old behavior, and new repositories get the new behavior. And you\nhave more flexibility in how your approach these problems when they\ncome up, and it seems to me that they are inevitable.\n\nCheers,\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"186538","messageId":"vpqobs65gfc.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"7vsjhi9wku.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-09T08:25:59Z","receivedAt":"2012-03-09T08:25:59Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> I just dug it up; start from here:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541\n\nThat's an old discussion. A more recent one is here:\n\n http://thread.gmane.org/gmane.comp.version-control.git/166743\n\n(interleaved with a discussion about tag namespace, but the end of the\nmessage is about push.default)\n\nIn this discussion, you (Junio) proposed a patch and argued exactly in\nthe direction I do right now. I think the discussion stopped here:\n\n http://thread.gmane.org/gmane.comp.version-control.git/166743\n\n(i.e. \"Care to roll an appliable patch?\", which I guess everyone has\nbeen too lazy to do)\n\nPatch follows.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186539","messageId":"1331281886-11667-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"29881","inReplyTo":"vpqobs65gfc.fsf@bauges.imag.fr","subject":"[RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-03-09T08:31:26Z","receivedAt":"2012-03-09T08:31:26Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"More inexperienced users will often push right after committing, and at\nthat time they're still very much in the \"working-on-one-branch\" state of\nmind. \"upstream\" would be a safer default mode of operation for 'git push'\nfor them even when they have their personal publishing repository (also in\na shared public repository settings, \"matching\" is rarely the right\ndefault mode).\n\nIn preparation for flipping the default to the \"upstream\" mode from the\n\"matching\" mode that is the upstream default, start warning users when they\nrely on unconfigured \"git push\" to default to the \"matching\" mode.\n\nOriginal patch and commit message by: Junio C Hamano \n\nSigned-off-by: Matthieu Moy \n---\n\nThis patch prepares a transition to 'upstream', unlike the previous\nversion which was advertizing 'current'. In most case, this would be\nthe same, but 'upstream' is probably more sensible in case it points\nto a branch other than 'current'. I don't care much either way.\n\nI've kept the wording from the original patch, which commits to a\nfuture change. We may instead relax this commitment and just say \"the\ndefault is likely to change in a future version\", or so.\n\n builtin/push.c | 22 ++++++++++++++++++++++\n cache.h | 1 +\n environment.c | 2 +-\n 3 files changed, 24 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex d315475..03545c0 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -91,10 +91,32 @@ static void setup_push_upstream(struct remote *remote)\n \tadd_refspec(refspec.buf);\n }\n \n+static void warn_unspecified_push_default_configuration(void)\n+{\n+\tstatic int warn_once;\n+\n+\tif (warn_once++)\n+\t\treturn;\n+\twarning(_(\"push.default is unset; its implicit value is changing in 1.8.0 from\\n\"\n+\t\t \"'matching' to 'upstream'. To squelch this message and maintain the current\\n\"\n+\t\t \"behavior post-1.8.0, use:\\n\"\n+\t\t \"\\n\"\n+\t\t \" git config --global push.default matching\\n\"\n+\t\t \"\\n\"\n+\t\t \"To squelch this message and adopt the 1.8.0 behavior now, use:\\n\"\n+\t\t \"\\n\"\n+\t\t \" git config --global push.default upstream\\n\"\n+\t\t \"\\n\"\n+\t\t \"See 'git help config' and search for 'push.default' for further information.\\n\"));\n+}\n+\n static void setup_default_push_refspecs(struct remote *remote)\n {\n \tswitch (push_default) {\n \tdefault:\n+\tcase PUSH_DEFAULT_UNSPECIFIED:\n+\t\twarn_unspecified_push_default_configuration();\n+\t\t/* fallthru */\n \tcase PUSH_DEFAULT_MATCHING:\n \t\tadd_refspec(\":\");\n \t\tbreak;\ndiff --git a/cache.h b/cache.h\nindex e12b15f..e5c3f26 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -622,6 +622,7 @@ enum rebase_setup_type {\n };\n \n enum push_default_type {\n+\tPUSH_DEFAULT_UNSPECIFIED = -1,\n \tPUSH_DEFAULT_NOTHING = 0,\n \tPUSH_DEFAULT_MATCHING,\n \tPUSH_DEFAULT_UPSTREAM,\ndiff --git a/environment.c b/environment.c\nindex c93b8f4..d7e6c65 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -52,7 +52,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;\n enum rebase_setup_type autorebase = AUTOREBASE_NEVER;\n-enum push_default_type push_default = PUSH_DEFAULT_MATCHING;\n+enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;\n #ifndef OBJECT_CREATION_MODE\n #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS\n #endif\n-- \n1.7.9.3.330.g598662\n"},{"id":"186540","messageId":"87aa3qi2i7.fsf@thomas.inf.ethz.ch","threadId":"29881","inReplyTo":"CANgJU+WMxnNgdsP4JV6aAVW07NeWXUa5LsEa4dk5_1CZXC1nXA@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2012-03-09T08:48:16Z","receivedAt":"2012-03-09T08:48:16Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"demerphq writes:\n\n> A possible solution might be to give config files a \"format version\"\n> of their own. They already contain a repository format version number,\n> so add a new variable \"ConfigVersionLevel\". Alongside that you might\n> introduce a policy of having new git \"fill in\" the defaults missing\n> from the config file whenever it operates, so that people can\n> explicitly view then all at once. Then if the defaults change in the\n> future an old repo will continue to work as it did before. This alone\n> would allow you to change the defaults for existing configurable\n> behavior, but you need the version number to handle new options.\n>\n> Once you have that you can change the default behavior based on the\n> version level so that older users operating in older repositories get\n> the old behavior, and new repositories get the new behavior. And you\n> have more flexibility in how your approach these problems when they\n> come up, and it seems to me that they are inevitable.\n\nThis would be a brilliant way to confuse the hell out of existing users:\nsuddenly the apparent \"defaults\"[1] now change *between repositories*\ndepending on when they were created.\n\nIn short, oh please god no.\n\n\n[1] using the word loosely here, for anything that the user has not\nconfigured manually with git-config, git-remote, git branch\n--set-upstream etc.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"186547","messageId":"7vipie85nk.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"vpqr4x26vyp.fsf@bauges.imag.fr","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T09:50:23Z","receivedAt":"2012-03-09T09:50:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> And regardless of the danger, if I look around me, I see almost only\n> people working with shared archives, and a few projects (including Git,\n> obviously) using the \"one commiter per repository\" workflow (I teach Git\n\nThese days, you do not have to even go to kernel.org to find people\nand projects that use \"publish to be pulled\" model. I hear that\nthere is a popular site called GitHub where people create their own\nfork, publish their work there and ask the project they forked from\nto pull their work.\n\nBy the way, don't we ask the workflow used by the users in the\nannual user survey?\n\n> to 200 students and several colleagues every year, I've tried teaching\n> the \"one public repository per developer\" and it was a complete disaster).\n\nInteresting. I have a couple of questions.\n\nWho are these 200 people and what do they do with Git? If the\nanswer is \"They work on a class assignment project, 20 teams of 10\nmembers each\", I would count that as a datapoint that represents one\nproject among thousands of projects that use Git.\n\nI am also curious to learn a bit more about \"a complete disaster\",\neven though this question (and its answer) would not be directly\nrelevant to this topic, as nobody is trying to convert projects to\nuse the \"publish to be pulled\" model when the \"push to the shared\ncentral repository\" model is more appropriate for them.\n"},{"id":"186548","messageId":"7vboo685nb.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"87aa3qi2i7.fsf@thomas.inf.ethz.ch","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T09:50:32Z","receivedAt":"2012-03-09T09:50:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> This would be a brilliant way to confuse the hell out of existing users:\n> suddenly the apparent \"defaults\"[1] now change *between repositories*\n> depending on when they were created.\n>\n> In short, oh please god no.\n\nAmen ;-)\n"},{"id":"186551","messageId":"7vwr6u6qrn.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"vpqobs65gfc.fsf@bauges.imag.fr","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T09:57:16Z","receivedAt":"2012-03-09T09:57:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> I just dug it up; start from here:\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541\n>\n> That's an old discussion. A more recent one is here:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/166743\n>\n> (interleaved with a discussion about tag namespace, but the end of the\n> message is about push.default)\n\nI'd say that it only shows that everybody for some strange reason\nforgot to learn from history, including me, in that more recent\nthread. Luckily, Jeff noticed eerily familiarity this time around.\n\n> (i.e. \"Care to roll an appliable patch?\", which I guess everyone has\n> been too lazy to do)\n\nI doubt that it would have solved any issue we suffered in the 1.6.3\nto 1.6.4 timeframe if somebody gave a concluding patch after that\nmessage in the more recent discussion. Specifically, it would not\nhave solved anything that these raised:\n\n http://thread.gmane.org/gmane.comp.version-control.git/118866/focus=119142\n http://thread.gmane.org/gmane.comp.version-control.git/118866/focus=119148\n\nResurrecting the old patch that was reverted is the easiest part.\n\nIt is much more important to spread the word to the people who will\nbe hurt by the default change well before it actually happens, and\nto get them engaged in the discussion, along with those who would\nbenefit from such a change. That needs to happen before any patch\nthat reverts a revert.\n\nEven in the kernel community, I suspect that most people do not\nfollow this mailing list anymore and simply trust that we won't make\nchanges that affect them negatively. People will complain only after\na change hits them, and tell us \"We didn't know that you will be\nmaking this stupid change.\" And having this thread here does not\ncount as \"spreading the word\".\n\nI can send a message saying \"There is a proposal to change the\ndefault behaviour of 'git push' on the Git mailing list, and you may\nbe negatively affected if you do not see anything in the output from\n'git config push.default' when such a change happens. On the other\nhand, you may want to see the default behaviour to change. In either\ncase, please join the discussion to give us more data point and help\nus decide the future of Git.\" to the kernel list. Anybody could, for\nthat matter.\n\nOne thing I refuse to do is to fight this battle alone for \"let's\nchange the default\" folks, especially when I am not convinced that\nit is a good change to begin with. It is \"let's change the default\"\nfolks' responsibility to help the legwork.\n"},{"id":"186552","messageId":"7vsjhi6qky.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"1331281886-11667-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T10:01:17Z","receivedAt":"2012-03-09T10:01:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> This patch prepares a transition to 'upstream', unlike the previous\n> version which was advertizing 'current'. In most case, this would be\n> the same, but 'upstream' is probably more sensible in case it points\n> to a branch other than 'current'. I don't care much either way.\n\nI would agree with that choice (provided that we were to do this\nchange).\n\n> I've kept the wording from the original patch, which commits to a\n> future change. We may instead relax this commitment and just say \"the\n> default is likely to change in a future version\", or so.\n\nPlease no. Keep it _very_ firmly committed. Otherwise we didn't\nlearn a thing from 1.6.3 era.\n"},{"id":"186553","messageId":"1331288715.21444.38.camel@beez.lab.cmartin.tk","threadId":"29881","inReplyTo":"1331281886-11667-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-03-09T10:25:15Z","receivedAt":"2012-03-09T10:25:15Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote:\n> More inexperienced users will often push right after committing, and at\n> that time they're still very much in the \"working-on-one-branch\" state of\n> mind. \"upstream\" would be a safer default mode of operation for 'git push'\n> for them even when they have their personal publishing repository (also in\n> a shared public repository settings, \"matching\" is rarely the right\n> default mode).\n> \n> In preparation for flipping the default to the \"upstream\" mode from the\n> \"matching\" mode that is the upstream default, start warning users when they\n> rely on unconfigured \"git push\" to default to the \"matching\" mode.\n> \n> Original patch and commit message by: Junio C Hamano \n> \n> Signed-off-by: Matthieu Moy \n> ---\n> \n> This patch prepares a transition to 'upstream', unlike the previous\n> version which was advertizing 'current'. In most case, this would be\n> the same, but 'upstream' is probably more sensible in case it points\n> to a branch other than 'current'. I don't care much either way.\n> \n\nFor people using git as VCS that happens to have local history rather\nthan taking full advantage of the distributed nature (or who aren't\naware of it or don't get it), 'matching' is bound to be confusing.\nHowever, IMO 'current' makes more sense. Consider\n\n git clone ../foo; cd foo;\n git checkout -b topic origin/develop\n ed main.c\n git push\n\nWith upstream I've just updated origin's dev branch, even though I might\nhave meant to create a new 'topic' branch. Alternatively, I might have\nrun\n\n git checkout -b topic\n\nin which case I certainly want 'current'. I don't see that workflow\nwhere the upstream branch is named differently from the local one should\nbe that big a consideration when trying to determine a default to help\npeople unfamiliar as they'd be certainly more likely to consider branch\nnames to be binding. Maybe you have seen this differently in your\nstudents, but that's the impression I get from #git.\n\nThey also seem to expect 'git pull' to be magic, but that's a different\nstory.\n\n> I've kept the wording from the original patch, which commits to a\n> future change. We may instead relax this commitment and just say \"the\n> default is likely to change in a future version\", or so.\n> \n> builtin/push.c | 22 ++++++++++++++++++++++\n> cache.h | 1 +\n> environment.c | 2 +-\n> 3 files changed, 24 insertions(+), 1 deletion(-)\n> \n> diff --git a/builtin/push.c b/builtin/push.c\n> index d315475..03545c0 100644\n> --- a/builtin/push.c\n> +++ b/builtin/push.c\n> @@ -91,10 +91,32 @@ static void setup_push_upstream(struct remote *remote)\n> \tadd_refspec(refspec.buf);\n> }\n> \n> +static void warn_unspecified_push_default_configuration(void)\n> +{\n> +\tstatic int warn_once;\n> +\n> +\tif (warn_once++)\n> +\t\treturn;\n> +\twarning(_(\"push.default is unset; its implicit value is changing in 1.8.0 from\\n\"\n> +\t\t \"'matching' to 'upstream'. To squelch this message and maintain the current\\n\"\n> +\t\t \"behavior post-1.8.0, use:\\n\"\n> +\t\t \"\\n\"\n> +\t\t \" git config --global push.default matching\\n\"\n> +\t\t \"\\n\"\n> +\t\t \"To squelch this message and adopt the 1.8.0 behavior now, use:\\n\"\n> +\t\t \"\\n\"\n> +\t\t \" git config --global push.default upstream\\n\"\n> +\t\t \"\\n\"\n> +\t\t \"See 'git help config' and search for 'push.default' for further information.\\n\"));\n> +}\n> +\n> static void setup_default_push_refspecs(struct remote *remote)\n> {\n> \tswitch (push_default) {\n> \tdefault:\n> +\tcase PUSH_DEFAULT_UNSPECIFIED:\n> +\t\twarn_unspecified_push_default_configuration();\n> +\t\t/* fallthru */\n> \tcase PUSH_DEFAULT_MATCHING:\n> \t\tadd_refspec(\":\");\n> \t\tbreak;\n> diff --git a/cache.h b/cache.h\n> index e12b15f..e5c3f26 100644\n> --- a/cache.h\n> +++ b/cache.h\n> @@ -622,6 +622,7 @@ enum rebase_setup_type {\n> };\n> \n> enum push_default_type {\n> +\tPUSH_DEFAULT_UNSPECIFIED = -1,\n> \tPUSH_DEFAULT_NOTHING = 0,\n> \tPUSH_DEFAULT_MATCHING,\n> \tPUSH_DEFAULT_UPSTREAM,\n> diff --git a/environment.c b/environment.c\n> index c93b8f4..d7e6c65 100644\n> --- a/environment.c\n> +++ b/environment.c\n> @@ -52,7 +52,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n> unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n> enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;\n> enum rebase_setup_type autorebase = AUTOREBASE_NEVER;\n> -enum push_default_type push_default = PUSH_DEFAULT_MATCHING;\n> +enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;\n> #ifndef OBJECT_CREATION_MODE\n> #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS\n> #endif\n\n\n"},{"id":"186555","messageId":"CACBZZX79co-BiePQG0ZkgMRiCWQ_g2NCZpVKYBNx=Rpi2WzgMQ@mail.gmail.com","threadId":"29881","inReplyTo":"1331281886-11667-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2012-03-09T11:26:47Z","receivedAt":"2012-03-09T11:26:47Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Mar 9, 2012 at 09:31, Matthieu Moy wrote:\n> More inexperienced users will often push right after committing, and at\n> that time they're still very much in the \"working-on-one-branch\" state of\n> mind.  \"upstream\" would be a safer default mode of operation for 'git push'\n> for them even when they have their personal publishing repository (also in\n> a shared public repository settings, \"matching\" is rarely the right\n> default mode).\n\nI very much like changing the default, thanks for working on this,\nthis'll make Git a lot more sensible by default.\n\n\n"},{"id":"186556","messageId":"CAFsnPqoWEv_Mp5-WXZo9TOjf67CxbNzuzeK_EikK20u0DuF3bQ@mail.gmail.com","threadId":"29881","inReplyTo":"7vipie85nk.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Jeremy Morton","fromEmail":"jeremy@configit.com","sentAt":"2012-03-09T11:28:58Z","receivedAt":"2012-03-09T11:28:58Z","isPatch":false,"sender":{"key":"jeremy@configit.com","avatar":null},"body":"On Fri, Mar 9, 2012 at 9:50 AM, Junio C Hamano wrote:\n> Matthieu Moy writes:\n>\n>> And regardless of the danger, if I look around me, I see almost only\n>> people working with shared archives, and a few projects (including Git,\n>> obviously) using the \"one commiter per repository\" workflow (I teach Git\n>\n> These days, you do not have to even go to kernel.org to find people\n> and projects that use \"publish to be pulled\" model.  I hear that\n> there is a popular site called GitHub where people create their own\n> fork, publish their work there and ask the project they forked from\n> to pull their work.\n\nGithub also offer a paid service where you can host private\nrepositories, which you're probably going to work on as part of a team\nin a business. FWIW, I discovered the problem with this default\nbehaviour because someone accidentally did a 'git push --force' to our\ngithub repo. There is currently no hook mechanism with github that\nallows you to abort a push, either, so you can't stop the problem that\nway.\n\nBest regards,\nJeremy Morton (Jez)\n"},{"id":"186557","messageId":"vpq8vjavvkt.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"7vipie85nk.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-09T11:54:10Z","receivedAt":"2012-03-09T11:54:10Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n>> to 200 students and several colleagues every year, I've tried teaching\n>> the \"one public repository per developer\" and it was a complete disaster).\n>\n> Interesting. I have a couple of questions.\n>\n> Who are these 200 people and what do they do with Git? If the\n> answer is \"They work on a class assignment project, 20 teams of 10\n> members each\",\n\nTeams are smaller, but that's essentially that, yes. I'm not saying it's\nrepresentative, my point just that I do have experience teaching Git to\nnew users.\n\n> I am also curious to learn a bit more about \"a complete disaster\",\n\nThere are several points:\n\n* It is often the case that one of the member of a team is more\n knowledgeable than others. Then, this user can set up a shared\n archive, and other users do not have to. When your project is\n open-source, it's rather easy to click GitHub's web interface and\n create a fork, but when it's a private project (and you don't want to\n pay), you have to do some kind of magic with ACLs or so to create a\n new repository. Doing this magic just once saves a lot of trouble.\n\n In practice, when working with colleagues (all being computer\n scientists), if I don't set up a shared repository, they just send me\n their files (yes, their files, not their patches :-( ) by email and\n ask me to do merges if needed.\n\n* Users like to know where \"the latest version\" is. They are already\n confused by the fact that the last local revision may not be the same\n as the last remote one, and having multiple public repositories adds\n to the confusion.\n\n> even though this question (and its answer) would not be directly\n> relevant to this topic, as nobody is trying to convert projects to\n> use the \"publish to be pulled\" model when the \"push to the shared\n> central repository\" model is more appropriate for them.\n\nSure. I'm not saying in any way that the \"shared repository\" is\nsuperior. Just that it's easier to grab for newbies.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186559","messageId":"vpq4ntyrn3c.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"7vwr6u6qrn.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-09T12:11:03Z","receivedAt":"2012-03-09T12:11:03Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> I can send a message saying \"[...]\" to the kernel list. Anybody could,\n> for that matter.\n\nThat would have been something sensible to do a few years ago, but\ntoday, I think we are far, far beyond the point where Git was a tool\nmeant primarily for kernel hackers. I don't think considering the kernel\ncommunity as more important than other users will help making Git easy\nto use for bare mortals.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186566","messageId":"m3mx7pzvia.fsf@localhost.localdomain","threadId":"29881","inReplyTo":"7vipie85nk.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-09T14:42:12Z","receivedAt":"2012-03-09T14:42:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[I'm sorry if you received duplicate]\n\nNb. instead of using `--force` to force push of all relevant branches,\nyou can always force push of single branch with `+branch`...\n\nJunio C Hamano writes:\n> Matthieu Moy writes:\n> \n> > And regardless of the danger, if I look around me, I see almost only\n> > people working with shared archives, and a few projects (including Git,\n> > obviously) using the \"one commiter per repository\" workflow (I teach Git\n> \n> These days, you do not have to even go to kernel.org to find people\n> and projects that use \"publish to be pulled\" model. I hear that\n> there is a popular site called GitHub where people create their own\n> fork, publish their work there and ask the project they forked from\n> to pull their work.\n> \n> By the way, don't we ask the workflow used by the users in the\n> annual user survey?\n\nThere is \"23) How do you publish/propagate your changes?\"[1] but it\ndoesn't tell if responder was using shared repository approach, or one\nfork per person approach.\n\nThis would be a good question to ask in this year, I think...\n \n[1]: https://www.survs.com/results/Q5CA9SKQ/P7DE07F0PL\n\n-- \nJakub Narebski\n"},{"id":"186567","messageId":"m3ipidzuxp.fsf@localhost.localdomain","threadId":"29881","inReplyTo":"7vwr6u6qrn.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-09T14:56:34Z","receivedAt":"2012-03-09T14:56:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[I am sorry if you have received duplicates]\n\nJunio C Hamano writes:\n> Matthieu Moy writes:\n>> Junio C Hamano writes:\n>>\n>>> I just dug it up; start from here:\n>>>\n>>> http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541\n>>\n>> That's an old discussion. A more recent one is here:\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/166743\n>>\n>> (interleaved with a discussion about tag namespace, but the end of the\n>> message is about push.default)\n> \n> I'd say that it only shows that everybody for some strange reason\n> forgot to learn from history, including me, in that more recent\n> thread. Luckily, Jeff noticed eerily familiarity this time around.\n\nNb. if I remember it correctly one of problems seen with transition to\nnew default was that there were no command-line equivalent to\n'push.default = matching'... but now we have \":\" and \"+:\" magic\nrefspec.\n\n>> (i.e. \"Care to roll an appliable patch?\", which I guess everyone has\n>> been too lazy to do)\n[...]\n\n> Resurrecting the old patch that was reverted is the easiest part.\n> \n> It is much more important to spread the word to the people who will\n> be hurt by the default change well before it actually happens, and\n> to get them engaged in the discussion, along with those who would\n> benefit from such a change. That needs to happen before any patch\n> that reverts a revert.\n> \n> Even in the kernel community, I suspect that most people do not\n> follow this mailing list anymore and simply trust that we won't make\n> changes that affect them negatively. People will complain only after\n> a change hits them, and tell us \"We didn't know that you will be\n> making this stupid change.\" And having this thread here does not\n> count as \"spreading the word\".\n> \n> I can send a message saying \"There is a proposal to change the\n> default behaviour of 'git push' on the Git mailing list, and you may\n> be negatively affected if you do not see anything in the output from\n> 'git config push.default' when such a change happens. On the other\n> hand, you may want to see the default behaviour to change. In either\n> case, please join the discussion to give us more data point and help\n> us decide the future of Git.\" to the kernel list. Anybody could, for\n> that matter.\n\nThere are other places where we can send such message beside git\nmailing list and LKML: There is Junio's \"Git Blame\" blog, there is Git\npage on Google+; we can ask for such annoncement to be posted also\non GitHub Blog...\n\nSpread the word...\n-- \nJakub Narebski\n"},{"id":"186569","messageId":"7vobs57nij.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"vpq4ntyrn3c.fsf@bauges.imag.fr","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T16:22:12Z","receivedAt":"2012-03-09T16:22:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> I can send a message saying \"[...]\" to the kernel list. Anybody could,\n>> for that matter.\n>\n> That would have been something sensible to do a few years ago, but\n> today, I think we are far, far beyond the point where Git was a tool\n> meant primarily for kernel hackers. I don't think considering the kernel\n> community as more important than other users will help making Git easy\n> to use for bare mortals.\n\nThat is *EXACTLY* the issue.\n\nThe kernel is one example community that *I* can cover, and if we\nwere going to continue discussion, I'm willing to help doing so\nbecause your change will *NEVER* work unless we spread the word to\n*all* the relevant communities whose members may be negatively\naffected. That is what I am saying in the part you quoted.\n\nBut I obviously *WILL* *NOT* be able to do so for *all* communities\nwhose members may be negatively affected.\n\nLet me repeat the part you omitted from your quote:\n\n One thing I refuse to do is to fight this battle alone for \"let's\n change the default\" folks, especially when I am not convinced that\n it is a good change to begin with. It is \"let's change the\n default\" folks' responsibility to help the legwork.\n\nNow, you have realized that the kernel community is only one of the\nplaces where \"let's change the default\" folks need to spread the\nword and solicit their involvement, are you willing to do your part?\n\nPeople will complain only after a change hits them, and tell us \"We\ndidn't know that you will be making this stupid change.\" And having\nthis thread here does not count as \"spreading the word\".\n"},{"id":"186570","messageId":"7vk42t7ngp.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"m3ipidzuxp.fsf@localhost.localdomain","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T16:23:18Z","receivedAt":"2012-03-09T16:23:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> There are other places where we can send such message beside git\n> mailing list and LKML: There is Junio's \"Git Blame\" blog, there is Git\n> page on Google+; we can ask for such annoncement to be posted also\n> on GitHub Blog...\n\nAnd you are saying who will do all of the above?\n"},{"id":"186574","messageId":"7v7gyt7joo.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"7vobs57nij.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T17:44:55Z","receivedAt":"2012-03-09T17:44:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> Junio C Hamano writes:\n>>\n>>> I can send a message saying \"[...]\" to the kernel list. Anybody could,\n>>> for that matter.\n>> ...\n> But I obviously *WILL* *NOT* be able to do so for *all* communities\n> whose members may be negatively affected.\n\nOh, let's avoid any misunderstanding before it happens.\n\nI am not saying that we need to get involvement only from people who\nmight like the current default. If you read the \"[...]\" part you\nomitted from your quote again, you will notice that the RFH message was\ncarefully crafted to take a neutral position, and solicit input from\nboth sides, and that was very much on purpose.\n\nI was hoping that the reaction to my reply would be that \"let's\nchange the default\" folks to help polishing the wording of the RFH\nmessage further, and post the final one to help spreading the word,\nboth in the forums of projects that will be helped by the change,\nand of those that will be irritated by the change.\n\nI didn't mean to suggest anybody to play politics by asking input\nfrom only one side to skew the discussion, even though it is not\nlike we will decide by majority vote anyway. Deciding in favor of\nwhichever position you happen to like is not the goal. Avoiding user\nsurprises and unnecessary harm is.\n\nAnd that is why the lesson the older thread from 1.6.3-1.6.4 era\nteaches us is important.\n"},{"id":"186577","messageId":"4F5A4C45.7070406@xiplink.com","threadId":"29881","inReplyTo":"1331288715.21444.38.camel@beez.lab.cmartin.tk","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-03-09T18:30:29Z","receivedAt":"2012-03-09T18:30:29Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-03-09 05:25 AM, Carlos Martín Nieto wrote:\n> On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote:\n>> More inexperienced users will often push right after committing, and at\n>> that time they're still very much in the \"working-on-one-branch\" state of\n>> mind. \"upstream\" would be a safer default mode of operation for 'git push'\n>> for them even when they have their personal publishing repository (also in\n>> a shared public repository settings, \"matching\" is rarely the right\n>> default mode).\n>>\n>> In preparation for flipping the default to the \"upstream\" mode from the\n>> \"matching\" mode that is the upstream default, start warning users when they\n>> rely on unconfigured \"git push\" to default to the \"matching\" mode.\n>>\n>> Original patch and commit message by: Junio C Hamano\n>>\n>> Signed-off-by: Matthieu Moy\n>> ---\n>>\n>> This patch prepares a transition to 'upstream', unlike the previous\n>> version which was advertizing 'current'. In most case, this would be\n>> the same, but 'upstream' is probably more sensible in case it points\n>> to a branch other than 'current'. I don't care much either way.\n>>\n>\n> For people using git as VCS that happens to have local history rather\n> than taking full advantage of the distributed nature (or who aren't\n> aware of it or don't get it), 'matching' is bound to be confusing.\n> However, IMO 'current' makes more sense. Consider\n>\n> git clone ../foo; cd foo;\n> git checkout -b topic origin/develop\n> ed main.c\n> git push\n>\n> With upstream I've just updated origin's dev branch, even though I might\n> have meant to create a new 'topic' branch. Alternatively, I might have\n> run\n>\n> git checkout -b topic\n>\n> in which case I certainly want 'current'. I don't see that workflow\n> where the upstream branch is named differently from the local one should\n> be that big a consideration when trying to determine a default to help\n> people unfamiliar as they'd be certainly more likely to consider branch\n> names to be binding. Maybe you have seen this differently in your\n> students, but that's the impression I get from #git.\n\nI disagree and consider \"upstream\" to be the more reasonable default.\n\nI think that an incantation like\n\n\tgit checkout -b topic origin/master\n\nmakes it pretty clear that topic is meant to be merged into origin's \nmaster branch. And so a simple \"git push\" as you describe I think \n*should* update origin's master branch.\n\nOTOH, with a default of \"current\" I believe the simple \"git push\" will \ncreate a new branch named topic in the origin repo. To me that's \nimplying too much from the simple \"git push\" command. If the user \nreally wants a branch named topic in the origin repo, I think it's \nreasonable for git's default behaviour to require the user to say so \nexplicitly (\"git push origin topic\").\n\nI also disagree that an incantation like\n\n\tgit checkout -b topic\n\nmeans that the user wants \"current\" when they \"git push\". There's no \nindication here that the user is at all interested in remote branches \nwith this topic, and I think it would be presumptuous for git to make \nsuch a link by default. (Besides, what if the user has more than one \nremote? Which should be used?)\n\nIn this case the \"upstream\" default would mean that git couldn't \nidentify a remote for the topic branch and so the \"git push\" would fail. \n I think that's appropriate, because the user never told git how the \ntopic branch relates to any remote branches.\n\n\t\tM.\n"},{"id":"186582","messageId":"7v62ed5xw2.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"7vsjhi6qky.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-09T20:21:01Z","receivedAt":"2012-03-09T20:21:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> This patch prepares a transition to 'upstream', unlike the previous\n>> version which was advertizing 'current'. In most case, this would be\n>> the same, but 'upstream' is probably more sensible in case it points\n>> to a branch other than 'current'. I don't care much either way.\n>\n> I would agree with that choice (provided that we were to do this\n> change).\n>\n>> I've kept the wording from the original patch, which commits to a\n>> future change. We may instead relax this commitment and just say \"the\n>> default is likely to change in a future version\", or so.\n>\n> Please no. Keep it _very_ firmly committed. Otherwise we didn't\n> learn a thing from 1.6.3 era.\n\nThe need for awareness building outside this mailing list remains,\nbut the ball is in the court of \"let's change the default\" folks and\nI cannot do anything further on that front, so I'll focus on the\npatch itself in this message.\n\nThe code seems quite competently done, except that the message text\nwould want to live in a separate static array, if only to keep the\nlines in the patch not overly long. Also, The message taken from\nJeff's $gmane/166787 may need to be tweaked further, waiting the\nconclusion of the discussion in the other subthread.\n\nOh, another thing is that the \"1.8.0\" in Jeff's original was written\nback in 1.7.5 era. We would want to bump it to say \"1.8\" (or even\n\"2.0\").\n\nThanks.\n"},{"id":"186585","messageId":"1kgpkt9.lt61vy108h530M%lists@haller-berlin.de","threadId":"29881","inReplyTo":"4F5A4C45.7070406@xiplink.com","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2012-03-09T21:08:30Z","receivedAt":"2012-03-09T21:08:30Z","isPatch":true,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"Marc Branchaud wrote:\n\n> I think that an incantation like\n> \n> git checkout -b topic origin/master\n> \n> makes it pretty clear that topic is meant to be merged into origin's \n> master branch. And so a simple \"git push\" as you describe I think \n> *should* update origin's master branch.\n\nNot for us, no. (But this is maybe a different topic.)\n\nIn our workflow (centralized repository), we never ever have a local\nbranch with a different name than its upstream branch. Never.\n\nWhen we say\n\n git checkout -b topic origin/master\n\nthen it's always a mistake, and what we really meant was\n\n git checkout -b --no-track topic origin/master\n\nThis has bitten us a few times in the past (people accidentally pushing\ntheir topic branches to master this way), and it's very annoying.\n\n\nBut coming back to the subject of push.default: in our environment,\n\"upstream\" is the only default that is useful with the current behaviour\nof git.\n\n(I could dream of a git mode where it's not necessary to explicitly set\nan upstream branch, and all git operations such as status, pull, or even\nsaying \"@{u}\" would automatically use \"remotes/origin/samename\" as the\nupstream branch. In that case, \"current\" would be a more convenient\ndefault value for push.default; but I guess that hypothetical mode would\nimply this anyway.)\n\n\n-- \nStefan Haller\nBerlin, Germany\nhttp://www.haller-berlin.de/\n"},{"id":"186611","messageId":"4F5AF1A8.4050604@alum.mit.edu","threadId":"29881","inReplyTo":"4F5A4C45.7070406@xiplink.com","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-03-10T06:16:08Z","receivedAt":"2012-03-10T06:16:08Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/09/2012 07:30 PM, Marc Branchaud wrote:\n> On 12-03-09 05:25 AM, Carlos Martín Nieto wrote:\n>> On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote:\n>>> This patch prepares a transition to 'upstream', unlike the previous\n>>> version which was advertizing 'current'. In most case, this would be\n>>> the same, but 'upstream' is probably more sensible in case it points\n>>> to a branch other than 'current'. I don't care much either way.\n>>>\n>>\n>> For people using git as VCS that happens to have local history rather\n>> than taking full advantage of the distributed nature (or who aren't\n>> aware of it or don't get it), 'matching' is bound to be confusing.\n>> However, IMO 'current' makes more sense. Consider\n>> [...]\n> \n> I disagree and consider \"upstream\" to be the more reasonable default.\n> [...]\n\nI think that either \"current\" or \"upstream\" would be an improvement on\nthe current behavior, but each of them is inappropriate in certain\nworkflows (even among centralized workflows).\n\nI propose that the default should be even stricter: like \"current\", it\nwould push to an branch with the same name as the current local branch,\n*but only if that branch already exists on the remote*. It would only\nbe possible to create a new branch on the remote by calling \"git push\"\nwith an explicit branch argument. I believe that such a policy would do\nthe right thing in the cases where the \"right thing\" is pretty\nunambiguous, and would require a user decision in other cases.\n\nOf course, users who have a strong preference for what is the \"right\nthing\" in the ambiguous case can fine-tune their local preference to\n\"current\" or \"upstream\"; this would amount to a relaxation of the strict\ndefault policy.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"186629","messageId":"7v62ec2mlf.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"1kgpkt9.lt61vy108h530M%lists@haller-berlin.de","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-10T21:05:32Z","receivedAt":"2012-03-10T21:05:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"lists@haller-berlin.de (Stefan Haller) writes:\n\n> Marc Branchaud wrote:\n>\n>> I think that an incantation like\n>> \n>> git checkout -b topic origin/master\n>> \n>> makes it pretty clear that topic is meant to be merged into origin's \n>> master branch. And so a simple \"git push\" as you describe I think \n>> *should* update origin's master branch.\n>\n> Not for us, no. (But this is maybe a different topic.)\n>\n> In our workflow (centralized repository), we never ever have a local\n> branch with a different name than its upstream branch. Never.\n>\n> When we say\n>\n> git checkout -b topic origin/master\n>\n> then it's always a mistake, and what we really meant was\n>\n> git checkout -b --no-track topic origin/master\n\nIt would have been nice if you explained larger picture of your\nworkflow, as almost anything else in life, a blanket statement like\nthe above is not a universal truth. It is clear you were aware of\nthat from your \"Not for *us*\", there is not enough clue for others\nto tell if their workflow is similar to yours to decide if the above\nrule of thumb of yours is a good one to follow for them.\n\nLet's illustrate what I mean by \"explain larger picture of workflow\"\nwith a few examples.\n\nAn example of where \"checkout -b topic origin/master\" would not be a\nmistake is when it is the norm for your project for contributors to\nintegrate their work with \"pull --rebase\", it is perfectly sensible\nfor a contributor to\n\n\tgit checkout -b frotz origin/master\n\nto start working on his feature \"frotz\", and way before the feature\nbecomes ready, starting to work on unrelated feature \"nitfol\" with\n\n\tgit checout -b nitfol origin/master\n\nand keep building these in parallel, running \"git pull --rebase\" to\nfloat yet-to-be-published his own work on updated the shared history\nbefore continuing to work on a topic until the feature is done. As\nthe contributor may not know upfront which of these independent\nfeatures will become ready when he starts working, it is sensible\nto be on the latter \"nitfol\" topic and \"git push\" it to update the\nshared history with the finished work on the branch.\n\nIn this case, you would want \"git push\" a branch to its @{upstream}.\n\nAnother example that \"checkout -b topic origin/master\" would not be\na mistake is when you fork your favorite project at GitHub, work on\ntwo independent topics. You work the same way as the above (you may\nnot \"pull --rebase\", though), and then push both of them out and ask\nthem to be pulled \"Please pull my 'frotz' and 'nitfol' branches\".\n\nIn this case, you would want \"git push\" a branch to update the\nbranch with the same name (i.e. either 'current' or 'matching').\n"},{"id":"186665","messageId":"1kgsxjq.jf2f02ib96ufM%lists@haller-berlin.de","threadId":"29881","inReplyTo":"7v62ec2mlf.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2012-03-11T20:26:35Z","receivedAt":"2012-03-11T20:26:35Z","isPatch":true,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"Junio C Hamano wrote:\n\n> lists@haller-berlin.de (Stefan Haller) writes:\n> \n> > When we say\n> >\n> > git checkout -b topic origin/master\n> >\n> > then it's always a mistake, and what we really meant was\n> >\n> > git checkout -b --no-track topic origin/master\n> \n> It would have been nice if you explained larger picture of your\n> workflow, as almost anything else in life, a blanket statement like\n> the above is not a universal truth.\n\nI wasn't saying that \"checkout -b topic origin/master\" isn't useful for\n*anybody*; it's just not useful for us. But you are right, I should\nhave explained who \"us\" is, and what our workflow is, sorry.\n\nWe're a closed-source company that uses git more or less like an\nold-style, non-distributed VCS. (This is not because \"we don't get it\",\nas someone phrased it elsewhere in this thread, but because it's what\nmakes most sense for us.)\n\nThe central repository has special significance, because it sends an\nemail for every commit, and it is hooked up to the CI system. For these\nreasons, everything that people work on is pushed to the central\nrepository, on a topic branch with the same name as the local branch.\nAlso, it is very common for two or more developers to collaborate on a\ntopic branch, and the central repository is the hub for this (developers\npull topics with \"pull --rebase\"). There's no direct exchange between\ndeveloper's clones, because others on the team wouldn't see a commit\nmail.\n\nTopics are never pushed to master; we have a \"merge --no-ff\" policy for\nintegration.\n\nSometimes, we need to branch a topic (let's call it B) off another topic\n(say A), because B needs some of A's code before it's integrated (we'll\nrebase B onto master once A is merged back, to keep the history clean).\nSame thing here: we say \"checkout -b B origin/A\", but we don't want to\nhave B's upstream to be set to origin/A. Again, we forgot to say\n--no-track.\n\nTo sum it up, push.default=current is almost perfect for this kind of\nworkflow; except that you still need to configure your upstream branches\nso that pull works, and status (and the shell prompt) displays the right\ninformation.\n\n\n-- \nStefan Haller\nBerlin, Germany\nhttp://www.haller-berlin.de/\n"},{"id":"186685","messageId":"vpqzkbmcijl.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"1kgsxjq.jf2f02ib96ufM%lists@haller-berlin.de","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-12T08:47:26Z","receivedAt":"2012-03-12T08:47:26Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"lists@haller-berlin.de (Stefan Haller) writes:\n\n> We're a closed-source company that uses git more or less like an\n> old-style, non-distributed VCS.\n> [...]\n> Also, it is very common for two or more developers to collaborate on a\n> topic branch,\n> [...]\n> Topics are never pushed to master; we have a \"merge --no-ff\" policy for\n> integration.\n> [...]\n> To sum it up, push.default=current is almost perfect for this kind of\n> workflow; except that you still need to configure your upstream branches\n> so that pull works, and status (and the shell prompt) displays the right\n> information.\n\nWhat do you set \"upstream\" to in your flow?\n\nI agree that push.default=current is the best setting for you. But I\nthink 'tracking' would not be a silly choice either: if you collaborate\non topic branches, it makes sense to set the upstream to the remote\ntopic branch, so that \"git pull\" gets changes in the same branch (and\nyou may need to \"git pull origin master\" to sync with the master branch\nfrom time to time). If you create a new branch with, say\n\n git checkout -b new-branch\n\nthen the new branch has no upstream configured, and the next push\nwithout argument will fail, pointing you to the right command for your\ncase:\n\n $ git push\n fatal: The current branch new-branch has no upstream branch.\n To push the current branch and set the remote as upstream, use\n \n git push --set-upstream origin new-branch\n\nIf you do a \"git checkout new-branch\" when \"origin/new-branch\" exists\nand \"new-branch\" doesn't, the upstream is configured to point to the\nremote \"new-branch\".\n\nIn both cases, the upstream is configured so that push.default=current\ndo the same thing as push.default=upstream, so you don't really care\nwhich value is taken.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186688","messageId":"vpqmx7mcgdz.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"7vwr6u6qrn.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-12T09:34:00Z","receivedAt":"2012-03-12T09:34:00Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> I can send a message saying \"There is a proposal to change the\n> default behaviour of 'git push' on the Git mailing list, and you may\n> be negatively affected if you do not see anything in the output from\n> 'git config push.default' when such a change happens. On the other\n> hand, you may want to see the default behaviour to change. In either\n> case, please join the discussion to give us more data point and help\n> us decide the future of Git.\" to the kernel list. Anybody could, for\n> that matter.\n\nHere's an attempt to an improved message. The first paragraph is here to\nmake sure people understand their opinion counts (before they stop\nreading because it's too long). The rest explains the change and the way\nto get involved:\n\n---------- 8< ---------- 8< -----------\n\nThere is a proposal to change the default behaviour of 'git push'\non the Git mailing list. The goal of this message is to encourage you\nto discuss it before it happens (or the change is aborted, depending\non the outcome of the discussion).\n\nIn the current setting (i.e. push.default=matching), 'git push' without\nargument will push all branches that exist locally and remotely with\nthe same name. This is usually appropriate when a developer pushes to\nhis own public repository, but confusing if not dangerous when using a\nshared repository. The proposal is to change the default to\n'upstream', i.e. push only the current branch, and push it to the\nupstream branch (the one 'git pull' would pull from). 'current' is\nanother candidate.\n\nFor more details on the behavior of Git with these values, read\nthe documentation about 'push.default' in 'man git-config'\n(http://schacon.github.com/git/git-config.html).\n\nYou may be negatively affected when such a change happens if you\ndo not see anything in the output from 'git config push.default'\nand if you rely on the fact that 'git push' pushes all your\nmatching branches. On the other hand, you may want to see the\ndefault behaviour to change, especially if you are using shared\nrepositories. In either case, please join the discussion to give\nus more data point and help us decide the future of Git.\n\nTo join the discussion, send your messages to: git@vger.kernel.org\nYou don't need to subscribe the list to post, and it's customary to\nCc: posters when replying on this list.\nTo view the current discussion, see this thread:\nhttp://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186692","messageId":"1kguf28.1u417v5fn74afM%lists@haller-berlin.de","threadId":"29881","inReplyTo":"vpqzkbmcijl.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2012-03-12T11:22:31Z","receivedAt":"2012-03-12T11:22:31Z","isPatch":true,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"Matthieu Moy wrote:\n\n> lists@haller-berlin.de (Stefan Haller) writes:\n> \n> > We're a closed-source company that uses git more or less like an\n> > old-style, non-distributed VCS.\n> > [...]\n> > Also, it is very common for two or more developers to collaborate on a\n> > topic branch,\n> > [...]\n> > Topics are never pushed to master; we have a \"merge --no-ff\" policy for\n> > integration.\n> > [...]\n> > To sum it up, push.default=current is almost perfect for this kind of\n> > workflow; except that you still need to configure your upstream branches\n> > so that pull works, and status (and the shell prompt) displays the right\n> > information.\n> \n> What do you set \"upstream\" to in your flow?\n\nThe remote topic branch with the same name.\n\n> I agree that push.default=current is the best setting for you. But I\n> think 'tracking' would not be a silly choice either: if you collaborate\n> on topic branches, it makes sense to set the upstream to the remote\n> topic branch, so that \"git pull\" gets changes in the same branch (and\n> you may need to \"git pull origin master\" to sync with the master branch\n> from time to time). If you create a new branch with, say\n> \n> git checkout -b new-branch\n> \n> then the new branch has no upstream configured, and the next push\n> without argument will fail, pointing you to the right command for your\n> case:\n> \n> $ git push\n> fatal: The current branch new-branch has no upstream branch.\n> To push the current branch and set the remote as upstream, use\n> \n> git push --set-upstream origin new-branch\n> \n> If you do a \"git checkout new-branch\" when \"origin/new-branch\" exists\n> and \"new-branch\" doesn't, the upstream is configured to point to the\n> remote \"new-branch\".\n\nYes, you describe exactly what we are doing. I am having two problems\nwith this way of working:\n\n1) After creating a new local topic branch, I must remember to use\n\"push -u origin new-branch\" the first time I push it. I don't want to\nhave to remember whether this is the first time I push; it would be nice\nto be able to say \"git push\" the first time as well.\n(push.default=current does this, but it's not good enough because I\nstill need the upstream branch configured so that pull works.)\n\n2) I get bitten by commands that configure the \"wrong\" upstream branch\nwithout me realizing it, like \"checkout -b topic origin/master\". Again,\npush.default=current helps somewhat because it avoids accidentally\npushing to the wrong branch; but it will still let me pull from the\nwrong branch; and it will confuse me because my shell prompt tells me\nI'm ahead of upstream even though I just pushed.\n\n\n-- \nStefan Haller\nBerlin, Germany\nhttp://www.haller-berlin.de/\n"},{"id":"186704","messageId":"vpq1uoyx9zh.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"1kguf28.1u417v5fn74afM%lists@haller-berlin.de","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-12T12:46:42Z","receivedAt":"2012-03-12T12:46:42Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"lists@haller-berlin.de (Stefan Haller) writes:\n\n> Matthieu Moy wrote:\n>\n>> What do you set \"upstream\" to in your flow?\n>\n> The remote topic branch with the same name.\n\nOK, so once it is configured, 'current' and 'upstream' do the same\nthing. The difference is how the upstream is configured, and what\nhappens if you forget to do it.\n\n> 1) After creating a new local topic branch, I must remember to use\n> \"push -u origin new-branch\" the first time I push it.\n\nFor this case, I'd say 'upstream' is superior to 'current', because it\nwill remind you to set the upstream on the first push, while 'current'\nwill let you silently continue with the upstream unconfigured (which you\nneed for 'pull' and 'status').\n\n> I don't want to have to remember whether this is the first time I\n> push; it would be nice to be able to say \"git push\" the first time as\n> well.\n\n(If you're going to work colaboratively, I'd say it makes sense to push\nan empty branch, just to let other people know that the branch is\ncreated, but that's not the point here)\n\nProbably the ideal command for you would be to allow something like\n\n git checkout -b topic origin/master --set-upstream=origin/topic\n\n> 2) I get bitten by commands that configure the \"wrong\" upstream branch\n> without me realizing it, like \"checkout -b topic origin/master\".\n\nYou may want to set branch.autosetupmerge to false, then. It will\ndisable the \"set upstream\" magic (but unfortunately, it will also\ndisable it for a plain \"git checkout new-branch\" which would create\nnew-branch automagically if origin/new-branch already exists).\n\nJust to be clear: I'm not saying that your workflow is wrong, but my\nfeeling is that you wouldn't be hurt by 'push.default=upstream'. The\narea of potential improvement for your case would be at branch creation\ntime more than at push time.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186719","messageId":"4F5E11EF.501@xiplink.com","threadId":"29881","inReplyTo":"1kgpkt9.lt61vy108h530M%lists@haller-berlin.de","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-03-12T15:10:39Z","receivedAt":"2012-03-12T15:10:39Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-03-09 04:08 PM, Stefan Haller wrote:\n> \n> But coming back to the subject of push.default: in our environment,\n> \"upstream\" is the only default that is useful with the current behaviour\n> of git.\n\nI'm not at all surprised -- everyone works differently. This is why the\ndefault is configurable in the first place.\n\nWhen it comes to what git should do by default, I think it's a bit pointless\nto have environment-vs-environment discussions. No matter how many people\njoin such a discussion on this list, it can only give us hints to which\ndefault would best serve git's users. Maybe the git survey can tell us what\nworkflows are most popular, but even that may not indicate the best default\nbehaviour.\n\nThe point I was trying to make in my previous message is that \"upstream\"\nseems like the least dangerous default behaviour. Yes, it does not match\neveryone's workflow. But it seems the least likely to shoot the feet off of\npeople who have yet to figure out their workflow at all.\n\n\t\tM.\n"},{"id":"186723","messageId":"4F5E12A5.6030701@xiplink.com","threadId":"29881","inReplyTo":"4F5AF1A8.4050604@alum.mit.edu","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-03-12T15:13:41Z","receivedAt":"2012-03-12T15:13:41Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-03-10 01:16 AM, Michael Haggerty wrote:\n> \n> I propose that the default should be even stricter: like \"current\", it\n> would push to an branch with the same name as the current local branch,\n> *but only if that branch already exists on the remote*. It would only\n> be possible to create a new branch on the remote by calling \"git push\"\n> with an explicit branch argument. I believe that such a policy would do\n> the right thing in the cases where the \"right thing\" is pretty\n> unambiguous, and would require a user decision in other cases.\n\nI haven't thought it through very deeply, but at first glance this seems like\nreasonable default behaviour to me.\n\n\t\tM.\n"},{"id":"186728","messageId":"7vobs1u7dr.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"vpq1uoyx9zh.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-12T16:11:12Z","receivedAt":"2012-03-12T16:11:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Just to be clear: I'm not saying that your workflow is wrong, but my\n> feeling is that you wouldn't be hurt by 'push.default=upstream'. The\n> area of potential improvement for your case would be at branch creation\n> time more than at push time.\n\nYour analysis of Stefan's pain points sounds very sensible.\nThe autoSetupMerge mechanism may want to learn new tricks, but that\nis a separate issue and it shouldn't affect the search for a sane\ndefault for push.\n"},{"id":"186735","messageId":"7vk42pu6io.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"vpqmx7mcgdz.fsf@bauges.imag.fr","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-12T16:29:51Z","receivedAt":"2012-03-12T16:29:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Here's an attempt to an improved message. The first paragraph is here to\n> make sure people understand their opinion counts (before they stop\n> reading because it's too long). The rest explains the change and the way\n> to get involved:\n\nSounds OK from a cursory read, except for a few minor details.\n\nThanks. Nitpicks follow.\n\n> ---------- 8< ---------- 8< -----------\n>\n> There is a proposal to change the default behaviour of 'git push'\n> on the Git mailing list. The goal of this message is to encourage you\n> to discuss it before it happens (or the change is aborted, depending\n> on the outcome of the discussion).\n>\n> In the current setting (i.e. push.default=matching), 'git push' without\n> argument will push all branches that exist locally and remotely with\n> the same name. This is usually appropriate when a developer pushes to\n> his own public repository, but confusing if not dangerous when using a\n> shared repository. The proposal is to change the default to\n\n\"usually appropriate\" tries to avoid claiming that this statement is\nthe final judgement. \"confusing\" may need to be stated the same\nway, i.e. \"but may be confusing\". Alternatively, we can drop \"usually\".\n\n> 'upstream', i.e. push only the current branch, and push it to the\n> upstream branch (the one 'git pull' would pull from). 'current' is\n> another candidate.\n\nWhen I find myself needing to clarify a jargon with parenthesized\nrephrase, I drop the jargon and parentheses and see if it makes it\neasier to read. And in this case I think it does.\n\n i.e. push only the current branch to the branch 'git pull' would\n pull from.\n\nWhat 'upstream' does is explained but not 'current'; here is my\nattempt.\n\n Another candidate is 'current'; this pushes only the current\n branch to the branch of the same name.\n\n> For more details on the behavior of Git with these values, read\n> the documentation about 'push.default' in 'man git-config'\n> (http://schacon.github.com/git/git-config.html).\n>\n> You may be negatively affected when such a change happens if you\n> do not see anything in the output from 'git config push.default'\n> and if you rely on the fact that 'git push' pushes all your\n> matching branches. On the other hand, you may want to see the\n\nLet's stress that they are relying on the _default_ a bit stronger.\n\n \"and if you rely on the default that pushes all your\"\n\n> default behaviour to change, especially if you are using shared\n> repositories. In either case, please join the discussion to give\n> us more data point and help us decide the future of Git.\n\n> To join the discussion, send your messages to: git@vger.kernel.org\n> You don't need to subscribe the list to post, and it's customary to\n> Cc: posters when replying on this list.\n> To view the current discussion, see this thread:\n> http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694\n\nAs this is not an invitation to start a new discussion, \"speak\nwithout reading what have already been said\" is not something we\nwould want to encourage, so I'd prefer to see the order swapped, like\n\n\tWhat has been discussed so far can be seen in these threads:\n\n \t... gmane references ...\n\n To join the discussion, send your messages to: git@vger.kernel.org\n The list accepts messages from non-subscribers, and you do\n not have to ask \"please Cc me, I am not subscribed\", as it's\n customary to Cc: posters when replying on this list.\n"},{"id":"186740","messageId":"vpqzkblixmb.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"4F5E12A5.6030701@xiplink.com","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-12T16:37:32Z","receivedAt":"2012-03-12T16:37:32Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Marc Branchaud writes:\n\n> On 12-03-10 01:16 AM, Michael Haggerty wrote:\n>> \n>> I propose that the default should be even stricter: like \"current\", it\n>> would push to an branch with the same name as the current local branch,\n>> *but only if that branch already exists on the remote*. It would only\n>> be possible to create a new branch on the remote by calling \"git push\"\n>> with an explicit branch argument. I believe that such a policy would do\n>> the right thing in the cases where the \"right thing\" is pretty\n>> unambiguous, and would require a user decision in other cases.\n>\n> I haven't thought it through very deeply, but at first glance this seems like\n> reasonable default behaviour to me.\n\nI do find it reasonable, but I think 'upstream' has several advantages\nover it.\n\n* 'upstream' makes \"git push\" and \"git pull\" symmetrical. While there\n are workflows where it is usefull to have \"push\" and \"pull\" point to\n different branches, I think it is far more intuitive to have this\n symmetry by default.\n\n* For newbies, the sequence \"create an empty repository, clone it,\n commit and push\" works like a charm with either 'upstream' or\n 'current'. Today, the first push to an empty repository requires\n either saying \"git push origin master\" or \"git push --all\", both of\n which sound like black magic to the poor user who did not yet learn\n what 'origin' is and what a branch is.\n\n* 'upstream' makes it easy to create a local topic branch, and let\n 'push' send it to the master branch (i.e. have local 'topic-branch'\n pull and push to 'origin/master'). In general, 'upstream' allows\n workflows where you push to branches with either a different name or\n with the same name (by setting the upstream appropriately), but the\n opposite is not true.\n\nThat being said, I think the mode you Michael described at least\ndeserves to exist, even if I disagree that it would be the best default.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186749","messageId":"7v8vj5u2n6.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"vpqzkblixmb.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-12T17:53:33Z","receivedAt":"2012-03-12T17:53:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> * 'upstream' makes \"git push\" and \"git pull\" symmetrical. While there\n> are workflows where it is usefull to have \"push\" and \"pull\" point to\n> different branches, I think it is far more intuitive to have this\n> symmetry by default.\n\nYes, \"by default\" is really the key word in this discussion, and I\nfind the above a sound reasoning.\n\n> ...\n> That being said, I think the mode you Michael described at least\n> deserves to exist, even if I disagree that it would be the best default.\n\nWhile I agree with that, I think the \"if and only if the destination\nalready exists\" falls into the same \"modifier\" category as \"force\"\nthat changes the behaviour of updating _one_ ref from the default\n\"only if it fast-forwards\" to \"even if it does not fast-forward\". I\nwould prefer this new modifier not to be tied too tightly to the\nMichael's magic mode, so that it can also be used when the refspecs\nare explicitly given.\n\nIn other words, with \"force\":\n\n\tgit push $there +pu\n\nupdates branch 'pu' over there even if it is not an ancestor of our\n'pu'. Similarly, may want to be able to say (I am *not* suggesting\nto use '?' as the motifier):\n\n\tgit push $there ?next\n\nto update next only if it exists over there and it is an ancestor of\nour 'next'.\n\nMaybe these modifiers can be combined, so that I can say\n\n\tfor there in k.org repo github sf.net\n do\n\t\tgit push $there maint master ?next ?+pu\n\tdone\n\nBecause the publishing point I have at sourceforge lack next and pu,\nthis will only update maint and master following the usual rules\nover there, but next and pu will be updated at other places.\n\nHmm?\n"},{"id":"186755","messageId":"20120312183725.GA2187@sigill.intra.peff.net","threadId":"29881","inReplyTo":"vpqzkblixmb.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-12T18:37:25Z","receivedAt":"2012-03-12T18:37:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote:\n\n> I do find it reasonable, but I think 'upstream' has several advantages\n> over it.\n> \n> * 'upstream' makes \"git push\" and \"git pull\" symmetrical. While there\n> are workflows where it is usefull to have \"push\" and \"pull\" point to\n> different branches, I think it is far more intuitive to have this\n> symmetry by default.\n\nThis is one of the things I really hate about 'upstream'. If you share a\ncentral repo with other people, it makes sense. You push and pull from\nthe same place. But in the classic kernel-style workflow, you'd pull\nfrom an upstream, and then publish your work elsewhere. And I think it's\nnot just kernel people who use this asymmetric workflow. On something\nlike GitHub, you get your own fork repo on the site as a publishing\npoint. But you also want to keep pulling and basing your work on what\nthe main project is doing. You can't just pull from your fork, since it\nnever gets updates from the main project; you pull them into your local\nrepo, and then push them up to your fork.\n\nSo in a very reasonable common newbie workflow, \"upstream\" will not at\nall do what you want, because it will go to the wrong repo[1]\n\nThat being said, \"current\" will _also_ go to the wrong repo, because\npush fundamentally respects \"branch.*.remote\". Which is definitely not\nwhat you want in the asymmetric case. This is not a push.default issue,\nbut I think it is somewhat related, and maybe worth discussing along\nwith the topic of asymmetry. Am I the only one who finds this behavior\nannoying? I've mostly trained my fingers to type \"git push\n\", but I do occasionally forget. Do other people with\nasymmetric workflows find this annoying? Do they not care? Or are many\nfewer people doing asymmetric things than I think?\n\nWhile I'm ranting, there's another weirdness I noticed. If I have\npush.default set to upstream, and config like this:\n\n [branch \"foo\"]\n remote = origin\n merge = refs/heads/master\n\nthen typing \"git push\" will go to foo's master branch. But if I type\n\"git push other-remote\", then it will go to other-remote's master\nbranch. Which makes no sense to me. The upstream is foo's master, and\nnow we are making guesses about how the names on each side are the same.\nIs this an intentional behavior?\n\n[1] One saving grace of going to the wrong repo is that you usually\n don't have permissions to push to that repo, so you get a harmless\n error message.\n\n> * For newbies, the sequence \"create an empty repository, clone it,\n> commit and push\" works like a charm with either 'upstream' or\n> 'current'. Today, the first push to an empty repository requires\n> either saying \"git push origin master\" or \"git push --all\", both of\n> which sound like black magic to the poor user who did not yet learn\n> what 'origin' is and what a branch is.\n\nEnding that confusion is one of the best reasons to switch the default,\nIMHO, but I don't think it argues for \"current\" versus \"upstream\", as\nthey both fix it (but Michael's matching-current hybrid would not, so I\nagree it is less appealing).\n\n> * 'upstream' makes it easy to create a local topic branch, and let\n> 'push' send it to the master branch (i.e. have local 'topic-branch'\n> pull and push to 'origin/master'). In general, 'upstream' allows\n> workflows where you push to branches with either a different name or\n> with the same name (by setting the upstream appropriately), but the\n> opposite is not true.\n\nActually, this is the thing that scares me the most about \"upstream\" as\na default, because in this case, you are implicitly performing the\nequivalent of a fast-forward merge. So that's handy if you are a new\nuser who wants to publish your work back to the master branch. But that\nhas two problems:\n\n 1. If you are a new user who does like the implicit merge, you may\n find it convenient not to have to learn about \"git checkout; git\n merge topic ; git push remote master\". But it only helps you\n _sometimes_. If master has had other work built on it, your push\n will fail, and you will have to do the merge yourself. So it is\n only helping you by omitting a step some of the time, and you still\n have to learn why the step is sometimes necessary and sometimes\n not.\n\n Yes, experienced users do not have this learning problem. But\n remember we are talking about a default targeted at new users, and\n trying to reduce their confusion. People who know and like what\n \"upstream\" does can configure it themselves.\n\n 2. If you are a new user who _doesn't_ want to do the merge, but\n instead wants to publish your work-in-progress topic, then the\n implicit merge-back-to-master behavior is wrong and dangerous.\n You are publishing work that probably violates the general rules\n for what goes on master.\n\n Or perhaps somebody else has built on top of master, and your push\n fails. If you're an astute reader, you will see that the failing\n push tried to go to master. But if you're not, you may retry with\n \"-f\", which is quite dangerous, as now you are not just\n accidentally publishing a work-in-progress, but you are\n overwriting somebody else's work. Obviously this is a problem\n anytime you use \"-f\", but the fact that your \"foo\" branch is going\n to somewhere besides the remote's \"foo\" branch makes me think it is\n much more likely a clueless user will get confused and overwrite\n something on the more \"mainstream\" branch.\n\nSo far a lot of the discussion has focused on \"what is the most sensible\ndefault for the most number of people\". But I wonder if a better\nquestion is \"what is the default that is the least likely to do\nsomething dangerous and embarrassing\". People who use git enough to say\n\"wow, I don't like this default for my workflow\" are probably at the\npoint that they can configure push.default themselves.\n\n-Peff\n"},{"id":"186761","messageId":"7vfwddskon.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"20120312183725.GA2187@sigill.intra.peff.net","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-12T19:06:48Z","receivedAt":"2012-03-12T19:06:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ... This is not a push.default issue,\n> but I think it is somewhat related, and maybe worth discussing along\n> with the topic of asymmetry. ...\n> I've mostly trained my fingers to type \"git push\n> \", but I do occasionally forget.\n\nIn an assymmetric set-up, you would typically push into one place\nbut update from one or more places, so it might make sense to make\nit easier to say \"git push\" and \"git pull $there\". But that does\nnot solve the fundamental issue, I would think.\n\n> Do other people with\n> asymmetric workflows find this annoying? Do they not care? Or are many\n> fewer people doing asymmetric things than I think?\n\nI think it is not \"they do not care\", but \"they do not have a good\nsolution\". I do not think of anything offhand, either.\n\n> While I'm ranting, there's another weirdness I noticed. If I have\n> push.default set to upstream, and config like this:\n>\n> [branch \"foo\"]\n> remote = origin\n> merge = refs/heads/master\n>\n> then typing \"git push\" will go to foo's master branch. But if I type\n> \"git push other-remote\", then it will go to other-remote's master\n> branch. Which makes no sense to me. The upstream is foo's master, and\n> now we are making guesses about how the names on each side are the same.\n> Is this an intentional behavior?\n\nBecause \"upstream\" is meant to be \"For the branch I am on, you know\nhow the branches map between the remote repository, so you already\nknow what the right thing to do---do it\" mode, the correct \"guess\"\nin your case is to error out and say \"Nah, you are not talking with\nyour upstream, so I do not have any clue what branches you want to\npush out and how. As you said that the push.default is upstream, not\nmatching, I refuse to even do the matching push in your case. This\nis an error. Be more specific\".\n\n> Actually, this is the thing that scares me the most about \"upstream\" as\n> a default, because in this case, you are implicitly performing the\n> equivalent of a fast-forward merge. So that's handy if you are a new\n> user who wants to publish your work back to the master branch. But that\n> has two problems:\n>\n> 1. If you are a new user who does like the implicit merge, you\n> may find it convenient not to have to learn about ... << and we\n> shouldn't discourage them from learning as it will be needed\n> anyway >>\n>\n> 2. If you are a new user who _doesn't_ want to do the merge, but\n> instead wants to publish your work-in-progress topic, then the\n> implicit merge-back-to-master behavior is wrong and dangerous.\n> << the newbie may push -f ruining the work of others >>\n\nI agree with both points. Also there is a cross-variant issue of\nthe above two:\n\n\tIf a new user hears \"not fast-forward, first pull and then\n\tpush again\", that will be done on a topic branch, merging\n\t'master' back and then pushing the result to 'master',\n\tleaving the 'master' of the user behind.\n\n> So far a lot of the discussion has focused on \"what is the most sensible\n> default for the most number of people\". But I wonder if a better\n> question is \"what is the default that is the least likely to do\n> something dangerous and embarrassing\". People who use git enough to say\n> \"wow, I don't like this default for my workflow\" are probably at the\n> point that they can configure push.default themselves.\n\nI do not think \"the most number of people\" is a high-priority issue,\nbut \"least damage\" default may not be necessarily the best.\n\nObviously, \"nothing\" is the least-damage option, and looking at how\neven people on this list cannot decide between current and upstream,\nI actually am very tempted to suggest it as the new default.\n"},{"id":"186767","messageId":"7v7gypsjgp.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"7vfwddskon.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-12T19:33:10Z","receivedAt":"2012-03-12T19:33:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> ... This is not a push.default issue,\n>> but I think it is somewhat related, and maybe worth discussing along\n>> with the topic of asymmetry. ...\n>> I've mostly trained my fingers to type \"git push\n>> \", but I do occasionally forget.\n>\n> In an assymmetric set-up, you would typically push into one place\n> but update from one or more places, so it might make sense to make\n> it easier to say \"git push\" and \"git pull $there\". But that does\n> not solve the fundamental issue, I would think.\n>\n>> Do other people with\n>> asymmetric workflows find this annoying? Do they not care? Or are many\n>> fewer people doing asymmetric things than I think?\n>\n> I think it is not \"they do not care\", but \"they do not have a good\n> solution\". I do not think of anything offhand, either.\n\nActually, we could introduce branch.$name.pushRemote that overrides\nbranch.$name.remote only for pushes.\n\nBefore anybody makes an ill-conceived comment, remote.$name.pushURL\nis not to be used for this purpose. It is only about how to get to\nthe named remote repository, and git still considers remote.$name to\nbe logically the same remote. \"git push\" into the named remote will\nstill update the remote tracking branch that we would update if we\nwere to immediately turn around and run \"git fetch\" from that same\nremote, and abusing remote.$name.pushURL for triangular setup will\nnot give us a correct behaviour.\n"},{"id":"186774","messageId":"4F5E598A.5020407@xiplink.com","threadId":"29881","inReplyTo":"7vfwddskon.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-03-12T20:16:10Z","receivedAt":"2012-03-12T20:16:10Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-03-12 03:06 PM, Junio C Hamano wrote:\n> Jeff King writes:\n>> \n>> So far a lot of the discussion has focused on \"what is the most sensible\n>> default for the most number of people\". But I wonder if a better\n>> question is \"what is the default that is the least likely to do\n>> something dangerous and embarrassing\". People who use git enough to say\n>> \"wow, I don't like this default for my workflow\" are probably at the\n>> point that they can configure push.default themselves.\n> \n> I do not think \"the most number of people\" is a high-priority issue,\n> but \"least damage\" default may not be necessarily the best.\n\nI agree, but I don't think we even have a good idea of what \"least damage\"\neven means. It seems to be vaguely related to how much of a hassle it would\nbe to recover from a plain \"git push\" doing the wrong thing.\n\nThere's one thing I'd like to ask all the folks who are pointing out how well\nthe candidate defaults match various workflows: How much training do you\ngive (or are assuming for) your workflow's new users?\n\nOr, more broadly, what is a \"new\" git user? Are we talking about someone\nusing git for the first time on a brand-new project that they're setting up\nthemselves? (Has that person even used any other VCS's?)\n\nOr is it someone who's joining an already-established team? Even a \"new\"\nuser hacking the Linux kernel or forking some github project is tying into an\nestablished process. And most every established process has either\ndocumentation (or a person) to explain how things are set up, and how to best\nconfigure git to work in that environment.\n\nIMHO git need not worry about \"new\" users joining an established process, if\nfor no other reason that it seems impossible to make git new-user-friendly in\nall (or even most) of those environments.\n\nInstead the focus should be on new users who are wrestling with git by\nthemselves (well, hopefully with the help whatever online documentation\nthey've found). They're making up their workflows as they go, refining them\nas they learn more about git. These are the users that git's defaults should\ncater to.\n\nAnd for those users, I still think \"upstream\" is the best of the current\ndefault candidates.\n\n> Obviously, \"nothing\" is the least-damage option, and looking at how\n> even people on this list cannot decide between current and upstream,\n> I actually am very tempted to suggest it as the new default.\n\nThere's a lot of merit to that. If nothing else, it'd get new users to learn\nat least a little bit about git. I wouldn't be opposed to pushing nothing by\ndefault.\n\n\t\tM.\n"},{"id":"186826","messageId":"vpqy5r44zg7.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"20120312183725.GA2187@sigill.intra.peff.net","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-13T09:34:00Z","receivedAt":"2012-03-13T09:34:00Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote:\n>\n>> * For newbies, the sequence \"create an empty repository, clone it,\n>> commit and push\" works like a charm with either 'upstream' or\n>> 'current'. Today, the first push to an empty repository requires\n>> either saying \"git push origin master\" or \"git push --all\", both of\n>> which sound like black magic to the poor user who did not yet learn\n>> what 'origin' is and what a branch is.\n>\n> Ending that confusion is one of the best reasons to switch the default,\n> IMHO, but I don't think it argues for \"current\" versus \"upstream\", as\n> they both fix it (but Michael's matching-current hybrid would not, so I\n> agree it is less appealing).\n\nExactly. It does not change the 'upstream' vs 'current' debate.\n\n>> * 'upstream' makes it easy to create a local topic branch, and let\n>> 'push' send it to the master branch (i.e. have local 'topic-branch'\n>> pull and push to 'origin/master'). In general, 'upstream' allows\n>> workflows where you push to branches with either a different name or\n>> with the same name (by setting the upstream appropriately), but the\n>> opposite is not true.\n>\n> Actually, this is the thing that scares me the most about \"upstream\" as\n> a default, because in this case, you are implicitly performing the\n> equivalent of a fast-forward merge. So that's handy if you are a new\n> user who wants to publish your work back to the master branch. But that\n> has two problems:\n>\n> 1. If you are a new user who does like the implicit merge, you may\n> find it convenient not to have to learn about \"git checkout; git\n> merge topic ; git push remote master\". But it only helps you\n> _sometimes_. If master has had other work built on it, your push\n> will fail, and you will have to do the merge yourself. So it is\n> only helping you by omitting a step some of the time, and you still\n> have to learn why the step is sometimes necessary and sometimes\n> not.\n\nThere's a rule of thumb which works very well for beginners: when \"git\npush\" tells you to pull before, then pull before. This rule of thumb\nworks, but only provided \"push\" and \"pull\" are symmetrical.\n\nMy experience with teaching Git is that this is the number 1 issue with\nbeginners (I'm talking about students who didn't learn CVS/SVN before,\nso real beginners). They try to push, the push fails, and they come to\nme saying \"Git is broken, we can't work\". That's why I introduced the\nadvice about non-fast forward, and later added the mention (e.g. 'git\npull') to point users in the right direction when the push fails. It\nconsiderably reduced my workload as teacher ;-).\n\nNow, if pushing sends commits to a branch other than 'upstream', you can\nget the following scenario:\n\n$ git push\nTo bla\n ! [rejected] master -> master (non-fast-forward)\nerror: failed to push some refs to 'bla'\nTo prevent you from losing history, non-fast-forward updates were rejected\nMerge the remote changes (e.g. 'git pull') before pushing again. See the\n'Note about fast-forwards' section of 'git push --help' for details.\n$ git pull\nAlready up-to-date.\n$ git push\n\n\nOne can easily get in this situation even in a kernel-style workflow:\nwork from your desktop, push, work from your laptop, try to push and it\nfails.\n\nBack to my students, most of them will never get in this situation\nbecause they won't use branch, so HEAD = master and upstream =\norigin/master, but the not-so-newbies may get this once they start\ncreating branches ifever they have HEAD = topic-branch and upstream =\norigin/master for example.\n\n> 2. If you are a new user who _doesn't_ want to do the merge, but\n> instead wants to publish your work-in-progress topic, then the\n> implicit merge-back-to-master behavior is wrong and dangerous.\n> You are publishing work that probably violates the general rules\n> for what goes on master.\n\nTo me, this is the real argument in favor of 'current'. I think it is\nless important than others, but that's obviously subjective.\n\nIn any case, I'm not opposed to 'current', and I think 'current' is a\nbetter default than 'matching', but I'm still not convinced it is better\nthan 'upstream'.\n\n> Or perhaps somebody else has built on top of master, and your push\n> fails. If you're an astute reader, you will see that the failing\n> push tried to go to master. But if you're not, you may retry with\n> \"-f\", which is quite dangerous, as now you are not just\n> accidentally publishing a work-in-progress, but you are\n> overwriting somebody else's work. Obviously this is a problem\n> anytime you use \"-f\", but the fact that your \"foo\" branch is going\n> to somewhere besides the remote's \"foo\" branch makes me think it is\n> much more likely a clueless user will get confused and overwrite\n> something on the more \"mainstream\" branch.\n\nI don't think 'current' Vs 'upstream' really changes that. You may get a\nnon-fast forward on your topic branch if you've push to it from another\nmachine for example.\n\n> So far a lot of the discussion has focused on \"what is the most sensible\n> default for the most number of people\". But I wonder if a better\n> question is \"what is the default that is the least likely to do\n> something dangerous and embarrassing\".\n\nI think \"what's the most intuitive\" is also very important. If we're\ntalking about real, real newbies, the risk of pushing to the wrong\nbranch is marginal compared to the risk of giving up and say \"Git\ndoesn't work, I'll send my files by email\" (which is real in my\nexperience :'-( ). But your remark does apply to not-totally newbies\nanymore, but not yet Git gurus.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186827","messageId":"vpqsjhc4zbg.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"7vfwddskon.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-13T09:36:51Z","receivedAt":"2012-03-13T09:36:51Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> ... This is not a push.default issue,\n>> but I think it is somewhat related, and maybe worth discussing along\n>> with the topic of asymmetry. ...\n>> I've mostly trained my fingers to type \"git push\n>> \", but I do occasionally forget.\n>\n> In an assymmetric set-up, you would typically push into one place\n> but update from one or more places, so it might make sense to make\n> it easier to say \"git push\" and \"git pull $there\". But that does\n> not solve the fundamental issue, I would think.\n\nIt does not solve it completely, but it makes it sensible to have\n'upstream' point to the place you are publishing to, and tell \"git pull\"\nexplicitely where you want to pull from. This is the way I work when I\nhave an asymmetrical setup (not the most common in my case).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186828","messageId":"vpqk42o4z5s.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"4F5E598A.5020407@xiplink.com","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-13T09:40:15Z","receivedAt":"2012-03-13T09:40:15Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Marc Branchaud writes:\n\n>> Obviously, \"nothing\" is the least-damage option, and looking at how\n>> even people on this list cannot decide between current and upstream,\n>> I actually am very tempted to suggest it as the new default.\n>\n> There's a lot of merit to that. If nothing else, it'd get new users to learn\n> at least a little bit about git. I wouldn't be opposed to pushing nothing by\n> default.\n\nThat would imply teching people what a branch is before teaching them\nvery basic workflows with push and pull.\n\nIf Git goes this route, I'll have to consider Mercurial instead of Git\nto teach revision control to my students ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186829","messageId":"vpqwr6o3k9s.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"7vk42pu6io.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-13T09:47:11Z","receivedAt":"2012-03-13T09:47:11Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> Here's an attempt to an improved message. The first paragraph is here to\n>> make sure people understand their opinion counts (before they stop\n>> reading because it's too long). The rest explains the change and the way\n>> to get involved:\n>\n> Sounds OK from a cursory read, except for a few minor details.\n>\n> Thanks. Nitpicks follow.\n\nI'm taking them all. Here's the result:\n\n---------- 8< ---------- 8< -----------\n\nThere is a proposal to change the default behaviour of 'git push'\non the Git mailing list. The goal of this message is to encourage you\nto discuss it before it happens (or the change is aborted, depending\non the outcome of the discussion).\n\nIn the current setting (i.e. push.default=matching), 'git push' without\nargument will push all branches that exist locally and remotely with the\nsame name. This is usually appropriate when a developer pushes to his\nown public repository, but may be confusing if not dangerous when using\na shared repository. The proposal is to change the default to\n'upstream', i.e. push only the current branch, and push it to the branch\n'git pull' would pull from. Another candidate is 'current'; this pushes\nonly the current branch to the remote branch of the same name.\n\nFor more details on the behavior of Git with these values, read\nthe documentation about 'push.default' in 'man git-config'\n(http://schacon.github.com/git/git-config.html).\n\nYou may be negatively affected when such a change happens if you do not\nsee anything in the output from 'git config push.default' and if you\nrely on the default that pushes all your matching branches. On the other\nhand, you may want to see the\n\ndefault behaviour to change, especially if you are using shared\nrepositories. In either case, please join the discussion to give\nus more data point and help us decide the future of Git.\n\nWhat has been discussed so far can be seen in this thread:\nhttp://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694\nPrevious relevant discussions include:\nhttp://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541\nhttp://thread.gmane.org/gmane.comp.version-control.git/166743\n\nTo join the discussion, send your messages to: git@vger.kernel.org\nThe list accepts messages from non-subscribers, and you do\nnot have to ask \"please Cc me, I am not subscribed\", as it's\ncustomary to Cc: posters when replying on this list.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186847","messageId":"7vlin4llwx.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"vpqwr6o3k9s.fsf@bauges.imag.fr","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-13T12:34:22Z","receivedAt":"2012-03-13T12:34:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n>> Sounds OK from a cursory read, except for a few minor details.\n>>\n>> Thanks. Nitpicks follow.\n>\n> I'm taking them all. Here's the result:\n\nI'd hold onto this version for a few days before I paste it in my\nblog or send it to k-list in order to give others a chance to\nimprove the text further, but this looks good (obviously) to me.\n\nThanks for getting the ball rolling.\n"},{"id":"186858","messageId":"7vehswljxi.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"vpqy5r44zg7.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-13T13:17:13Z","receivedAt":"2012-03-13T13:17:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> There's a rule of thumb which works very well for beginners: when \"git\n> push\" tells you to pull before, then pull before. This rule of thumb\n> works, but only provided \"push\" and \"pull\" are symmetrical.\n\nI actually think the \"pull before push again\" was written with only\nCVS style non-branching workflow in mind, in other words, only to\nhelp somebody who works on his master against the central master.\nObviously \"push and pull are symmetrical\" holds true for that single\nbranch workflow, but that does not mean a more complex workflow must\nbe symmetrical.\n\nEven though I think 'upstream' will be a superset of what 'current'\nwants to do in an ideal world where the user configures everything\nright (hence it ought to be the better default between the two), I\ndo not think that the target audience \"let's change the default\"\nfolks are trying to help is those who set @{upstream} correctly\npoint the destination for a branch they want to push to and leave it\nunset for a strictly private branch. If we choose the default that\nwould primarily make it efficient for people who can configure\neverything right, we are missing the point of this discussion. I\nthink the target audience to be helped is the people who do not\n(yet) do anything complex, and the point of this discussion is to\nhelp them avoid getting surprised.\n\nAnd by \"surprised\", I do not necessarily mean \"dangerous\". While we\nshould aim to avoid \"dangerous\", we should avoid \"ununderstandable\"\neven more.\n\nPushing 'current' from a branch 'topic' forked from either 'master'\nor 'origin/master' will create a new branch 'topic' at the central\nrepository. But that is straightforward and understandable. The user\nwill see what happened in the feedback from the command, and there\nis no need for the user to be experienced enough to know the mapping\nof @{upstream} to understand why it happened. \"I am on 'topic' and\nI pushed, I created 'topic' there\". Very simple explanation exists.\n\nOn the other hand, the user needs to know not just 'branch' but also\nunderstand the concept of @{upstream} in order to use 'upstream'\nwithout surprise. When something goes wrong, prerequisite knowledge\nthat is required to understand it is greater. Also the current\nimplementation of 'upstream' has some weird semantics (or undesigned\nbugs) pointed out by Peff, which would make it even more confusing.\n\nThat makes me suspect that 'current' might be a more appropriate\ndefault between the two. From that simple default, those in the\n\"shared central repository\" world can graduate to 'upstream' once\nthey know what an 'upstream' is and how to take advantage of\nper-branch configuration. Similarly, those in the \"publish to be\npulled\" world would graduate to 'matching'.\n"},{"id":"186859","messageId":"vpqaa3kfwss.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"7vehswljxi.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-13T13:35:47Z","receivedAt":"2012-03-13T13:35:47Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> I actually think the \"pull before push again\" was written with only\n> CVS style non-branching workflow in mind, in other words, only to\n> help somebody who works on his master against the central master.\n\nIt doesn't have much to do with branching/non-branching. You may use\nbranches, and still work collaboratively on them. There was an example\nabove in the same thread:\n\n http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694\n\nThere are also cases like \"I pushed from my laptop and I'm back to my\ndesktop\", or \"the content has been edited from GitHub's web interface\".\n\nActually, I hardly see a case where \"pull before push again\" (with or\nwithout --rebase or such) is wrong for a beginner.\n\n> Pushing 'current' from a branch 'topic' forked from either 'master'\n> or 'origin/master' will create a new branch 'topic' at the central\n> repository. But that is straightforward and understandable. The user\n> will see what happened in the feedback from the command, and there\n> is no need for the user to be experienced enough to know the mapping\n> of @{upstream} to understand why it happened. \"I am on 'topic' and\n> I pushed, I created 'topic' there\". Very simple explanation exists.\n\nVery simple explanation exist for what \"push\" does, but not for \"the\nglobal picture of what push and pull do\". And really, the case \"Git\nprevents me from pushing, I don't know what to do\" is a problem for\npeople who don't get the whole remote/branch/upstream/... things.\n\nActually, I'm starting to wonder if the whole \"upstream\" thing should\nnot be deactivated by default, and replaced with a simpler mechanism\nlike \"pull.default\", similar to what \"push.default\" does today. Then,\nusers could set \"pull.default=current\", and \"git pull\" would pull a\nbranch with the same name remotely. Or users could set\n\"pull.default=upstream\" and get what Git does today.\n\nBut that's a much larger change, then ...\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186863","messageId":"4F5F5A3F.8010102@xiplink.com","threadId":"29881","inReplyTo":"7vehswljxi.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-03-13T14:31:27Z","receivedAt":"2012-03-13T14:31:27Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-03-13 09:17 AM, Junio C Hamano wrote:\n> Matthieu Moy writes:\n> \n>> There's a rule of thumb which works very well for beginners: when \"git\n>> push\" tells you to pull before, then pull before. This rule of thumb\n>> works, but only provided \"push\" and \"pull\" are symmetrical.\n> \n> I actually think the \"pull before push again\" was written with only\n> CVS style non-branching workflow in mind, in other words, only to\n> help somebody who works on his master against the central master.\n> Obviously \"push and pull are symmetrical\" holds true for that single\n> branch workflow, but that does not mean a more complex workflow must\n> be symmetrical.\n> \n> Even though I think 'upstream' will be a superset of what 'current'\n> wants to do in an ideal world where the user configures everything\n> right (hence it ought to be the better default between the two), I\n> do not think that the target audience \"let's change the default\"\n> folks are trying to help is those who set @{upstream} correctly\n> point the destination for a branch they want to push to and leave it\n> unset for a strictly private branch. If we choose the default that\n> would primarily make it efficient for people who can configure\n> everything right, we are missing the point of this discussion. I\n> think the target audience to be helped is the people who do not\n> (yet) do anything complex, and the point of this discussion is to\n> help them avoid getting surprised.\n> \n> And by \"surprised\", I do not necessarily mean \"dangerous\". While we\n> should aim to avoid \"dangerous\", we should avoid \"ununderstandable\"\n> even more.\n> \n> Pushing 'current' from a branch 'topic' forked from either 'master'\n> or 'origin/master' will create a new branch 'topic' at the central\n> repository. But that is straightforward and understandable. The user\n> will see what happened in the feedback from the command, and there\n> is no need for the user to be experienced enough to know the mapping\n> of @{upstream} to understand why it happened. \"I am on 'topic' and\n> I pushed, I created 'topic' there\". Very simple explanation exists.\n> \n> On the other hand, the user needs to know not just 'branch' but also\n> understand the concept of @{upstream} in order to use 'upstream'\n> without surprise. When something goes wrong, prerequisite knowledge\n> that is required to understand it is greater. Also the current\n> implementation of 'upstream' has some weird semantics (or undesigned\n> bugs) pointed out by Peff, which would make it even more confusing.\n> \n> That makes me suspect that 'current' might be a more appropriate\n> default between the two. From that simple default, those in the\n> \"shared central repository\" world can graduate to 'upstream' once\n> they know what an 'upstream' is and how to take advantage of\n> per-branch configuration. Similarly, those in the \"publish to be\n> pulled\" world would graduate to 'matching'.\n\nGood points!\n\nI think someone who's figuring out their workflow as they go would appreciate\nthe simplicity offered by \"current\".\n\nYou've changed my mind: I now think \"current\" is the better default.\n\n\t\tM.\n"},{"id":"186865","messageId":"4F5F60C5.6020900@ira.uka.de","threadId":"29881","inReplyTo":"7vehswljxi.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-03-13T14:59:17Z","receivedAt":"2012-03-13T14:59:17Z","isPatch":true,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 13.03.2012 14:17, Junio C Hamano wrote:\n> that is required to understand it is greater. Also the current\n> implementation of 'upstream' has some weird semantics (or undesigned\n> bugs) pointed out by Peff, which would make it even more confusing.\n\nIf Peff's \"push to same branch in a different remote\" is a bug (and IMHO \nit is) it should not count as a reason for what should be the default.\n\nOne small point in favor of \"current\" I haven't seen mentioned: It is \nthe smaller/more compatible change from the \"matching\" behaviour.\n\nThe most important point for me in the discussion up till now (because \nit matches my newbie experiences): It doesn't matter that much for new \nusers whether \"current\" or \"upstream\" is default, because they mostly \nwork on master and create branches from local master.\n\nBut in that case the typical situation where the default comes into play \nwill be when they accidentally are on a branch other than master and try \nto use 'git push'. In that case \"current\" would push (wrongly) to a \nsimilar named branch on the remote while upstream would not because the \nlocal branch would have no upstream configured. Small point in favor of \n\"upstream\"\n\nThe symmetry is what really makes me vote for \"upstream\". Both \n\"upstream\" and \"current\" play to the expectations of new users, \n\"upstream\" because of the symmetry and \"current\" because they usually \nexpect some connection between branches of the same name in different \nrepositories. But only upstream will help those who want to cure git \npush with git pull. And that would be the whole crowd having just a \nwhiff of experience with cvs or svn. And if I could take a guess, that \nis the case for the majority of computer science students at a typical \nuniversity (the rest mostly having no experience with version control at \nall)\n\n\n\nBy the way, the documentation is very confusing in its description what \ngit push without parameters does. For example it is not really explained \nin the description or options part, the only explanation is in the \nExamples. There \"git push\" points to \"git push origin\" and:\n-------------\n\"git push origin\n Without additional configuration, works like git push origin :.\n\n The default behavior of this command when no is \ngiven can be configured by setting the push option of the\n remote.\n------------\n\nNow the refspec documentation never says anything about what '.' means \n(the only docu about refspecs I could find is in pull-fetch-param.txt \nthat is included by git-fetch and git-pull. I thought there was another \nmanpage about refspecs but I couldn't find it).\nAnd shouldn't the second sentence above be \"... can be configured by \nsetting the push.default option of the remote\" ?\n\nIs this patchworthy (in that case I'll try to make one) or did I just \nnot read at the right places?\n"},{"id":"186866","messageId":"4F5F619A.3040806@op5.se","threadId":"29881","inReplyTo":"7vehswljxi.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-03-13T15:02:50Z","receivedAt":"2012-03-13T15:02:50Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 03/13/2012 02:17 PM, Junio C Hamano wrote:\n> Matthieu Moy writes:\n> \n>> There's a rule of thumb which works very well for beginners: when \"git\n>> push\" tells you to pull before, then pull before. This rule of thumb\n>> works, but only provided \"push\" and \"pull\" are symmetrical.\n> \n> I actually think the \"pull before push again\" was written with only\n> CVS style non-branching workflow in mind, in other words, only to\n> help somebody who works on his master against the central master.\n> Obviously \"push and pull are symmetrical\" holds true for that single\n> branch workflow, but that does not mean a more complex workflow must\n> be symmetrical.\n> \n> Even though I think 'upstream' will be a superset of what 'current'\n> wants to do in an ideal world where the user configures everything\n> right (hence it ought to be the better default between the two), I\n> do not think that the target audience \"let's change the default\"\n> folks are trying to help is those who set @{upstream} correctly\n> point the destination for a branch they want to push to and leave it\n> unset for a strictly private branch. If we choose the default that\n> would primarily make it efficient for people who can configure\n> everything right, we are missing the point of this discussion. I\n> think the target audience to be helped is the people who do not\n> (yet) do anything complex, and the point of this discussion is to\n> help them avoid getting surprised.\n> \n> And by \"surprised\", I do not necessarily mean \"dangerous\". While we\n> should aim to avoid \"dangerous\", we should avoid \"ununderstandable\"\n> even more.\n> \n> Pushing 'current' from a branch 'topic' forked from either 'master'\n> or 'origin/master' will create a new branch 'topic' at the central\n> repository. But that is straightforward and understandable. The user\n> will see what happened in the feedback from the command, and there\n> is no need for the user to be experienced enough to know the mapping\n> of @{upstream} to understand why it happened. \"I am on 'topic' and\n> I pushed, I created 'topic' there\". Very simple explanation exists.\n> \n> On the other hand, the user needs to know not just 'branch' but also\n> understand the concept of @{upstream} in order to use 'upstream'\n> without surprise. When something goes wrong, prerequisite knowledge\n> that is required to understand it is greater. Also the current\n> implementation of 'upstream' has some weird semantics (or undesigned\n> bugs) pointed out by Peff, which would make it even more confusing.\n> \n> That makes me suspect that 'current' might be a more appropriate\n> default between the two. From that simple default, those in the\n> \"shared central repository\" world can graduate to 'upstream' once\n> they know what an 'upstream' is and how to take advantage of\n> per-branch configuration. Similarly, those in the \"publish to be\n> pulled\" world would graduate to 'matching'.\n\n\nSensible sentiments, sir.\n\nEven with advanced usage, 'current' is what I think does the right\nthing in 99% of all cases, and it errs on the side of \"least extra\nwork when things go wrong\".\n\nThe questions to ask, I think, are these:\n* What would newcomers to git expect?\nYou answered this nicely.\n\n* What does advanced users use *most of the time*?\nAt $dayjob, 99.9% of all pushes are to get the changes of the current\nbranch to the sharepoint repo. Once in a while (when tagging, usually\nwhatnot) for some repositories, I wish to push maint and master to a\npublic repository for the masses to use. This happens roughly once\nevery 200 commits, according to a quick \"git log\" in two repos, but\nonly for about 10 or so of the 60-odd repos we're maintaining, and\nonly for two of the six developers working on them.\nIt's very rare that I work on multiple already-created topics and\nthey all finish at the same time. At most, I wish to push \"maint\"\nand \"master\" in one go.\n\nIf I notice I've done the bad push, I need to make sure noone else\nfetched the thing during the time it takes me to undo the push, or\nI may have to quickly fix up the potentially broken branch. Either\nway, it can be a lot of work that I rarely have time for right then.\n\n\n* What causes the least damage when the default is less suitable?\nQuite a few times I've managed to push work-in-progress commits to\nrandom topics at work with the default \"matching\". If I miss that\nI've done so, undoing the damage is a great big pain in the butt,\nsince it means either force-pushing to sharepoint or un-bisectable\ncommits. The worst case for \"current\" would be if I merge one branch\nto master, forget to push the merged branch but do push 'master'\nto our sharepoint, and then someone else comes along and works a\nbit more on the topic I accidentally didn't push. When that happens,\nI can quite easily rebase my changes on top of the other devs, or\nmerge with the sharepoint changes, and then re-merge to master\nwithout having to call a flag-day for the devs working on the same\nproject.\n\nIf I notice I've forgotten to push, I can just push again immediately\nand git will handle any errors for me. It never leads to any extra\nwork for me, and never stalls anyone else from progressing with their\nown tasks.\n\n\nIn light of that, \"current\" is really the only sensible way to go.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"186867","messageId":"201203131618.33072.jnareb@gmail.com","threadId":"29881","inReplyTo":"7vk42t7ngp.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-13T15:18:31Z","receivedAt":"2012-03-13T15:18:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 9 Mar 2012, Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n> > There are other places where we can send such message beside git\n> > mailing list and LKML: There is Junio's \"Git Blame\" blog, there is Git\n> > page on Google+; we can ask for such annoncement to be posted also\n> > on GitHub Blog...\n> \n> And you are saying who will do all of the above?\n\nI would certainly not be announcing this message on yours \"Git Blame\"\nblog, and you usually accompany new post on blog with announcement on G+\n(I don't remember if via \"Git\" page or via your own personal Google+\npage).\n\nI can go round git hosting sites asking to post announcements, similarly\nto what I do during annual \"Git User's Survey\".\n-- \nJakub Narebski\nPoland\n"},{"id":"186869","messageId":"201203131627.30455.jnareb@gmail.com","threadId":"29881","inReplyTo":"CAFsnPqqJt13gDp2RNiEU4dt59iMwFvMzysfk51mO8aF+_nYGXA@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-13T15:27:30Z","receivedAt":"2012-03-13T15:27:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 8 Mar 2012, Jeremy Morton wrote:\n> On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski wrote:\n\n> > You can always configure server to refuse forced pushes.\n> \n> We're using github, and as far as I'm aware, there's no way to\n> configure github to do that.\n\nIt would be nice if GitHub supported setting receive.denyNonFastForward\nand receive.denyDeletes (the receive.*current* do not matter for GitHub).\nThough I am not sure if it would not require changes to the custom Git\nimplementation they use...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"186875","messageId":"7v7gyoxuth.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"4F5F60C5.6020900@ira.uka.de","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-13T17:41:14Z","receivedAt":"2012-03-13T17:41:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Holger Hellmuth writes:\n\n> On 13.03.2012 14:17, Junio C Hamano wrote:\n>> that is required to understand it is greater. Also the current\n>> implementation of 'upstream' has some weird semantics (or undesigned\n>> bugs) pointed out by Peff, which would make it even more confusing.\n>\n> If Peff's \"push to same branch in a different remote\" is a bug (and\n> IMHO it is) it should not count as a reason for what should be the\n> default.\n\nI may phrased it poorly, but I don't think you mean \"if the bug is fixed,\nthen the behaviour of upstream is simple and easy to understand\". The\nvery reason the bug exists in the first place is that the semantics that\nmode wants to give its users is complex enough that even the people who\nshould know (i.e. those who implement it) overlooked that there is a\ncorner case their implementation was not handling. It is a demonstration\nthat upstream is not an easy-to-understand choice to throw at new people.\n\n> By the way, the documentation is very confusing in its description\n> what git push without parameters does. For example it is not really\n> explained in the description or options part, the only explanation is\n> in the Examples. There \"git push\" points to \"git push origin\" and:\n> -------------\n> \"git push origin\n> Without additional configuration, works like git push origin :.\n>\n> The default behavior of this command when no is\n> given can be configured by setting the push option of the\n> remote.\n> ------------\n>\n> Now the refspec documentation never says anything about what '.' means\n> (the only docu about refspecs I could find is in pull-fetch-param.txt\n\nThat should read:\n\n\t... works like \"git push origin :\".\n\nThat dot you see after the colon is a full-stop for the sentence, not a\npart of any refspec.\n\n\n> Is this patchworthy (in that case I'll try to make one) or did I just\n> not read at the right places?\n\nIt is patch-worthy; you already know that it made you waste time looking\nfor ':.'---the documentation shouldn't have done that.\n"},{"id":"186884","messageId":"CAHkcotg1FKxfMR4Fe9Xfo_i4nuxzXdfVWe80HZu0wQEkiXhhmA@mail.gmail.com","threadId":"29881","inReplyTo":"vpqy5r44zg7.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2012-03-13T18:08:52Z","receivedAt":"2012-03-13T18:08:52Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Mar 13, 2012 at 1:34 PM, Matthieu Moy\n wrote:\n> Jeff King writes:\n>\n>>   1. If you are a new user who does like the implicit merge, you may\n>>      find it convenient not to have to learn about \"git checkout; git\n>>      merge topic ; git push remote master\". But it only helps you\n>>      _sometimes_. If master has had other work built on it, your push\n>>      will fail, and you will have to do the merge yourself. So it is\n>>      only helping you by omitting a step some of the time, and you still\n>>      have to learn why the step is sometimes necessary and sometimes\n>>      not.\n>\n> There's a rule of thumb which works very well for beginners: when \"git\n> push\" tells you to pull before, then pull before. This rule of thumb\n> works, but only provided \"push\" and \"pull\" are symmetrical.\n\nI am not sure what you mean by symmetrical here, because they are never\ntruly symmetrical as \"pull\" does merge and \"push\" does not. If there is\na centralized workflow with only one branch then everything is simple,\nbut it is not so with other workflows.\n\nMoreover, doing 'git pull' too often (unless it is 'git pull --rebase)\npollutes history with useless merges, making more difficult to review\nchanges, or doing git-bisect.\n\n> Now, if pushing sends commits to a branch other than 'upstream', you can\n> get the following scenario:\n>\n> $ git push\n> To bla\n>  ! [rejected]        master -> master (non-fast-forward)\n> error: failed to push some refs to 'bla'\n\nI agree that the current diagnostic is not suitable for beginners.\nNot-fast-forward push is something that beginners should never use,\nbut from this message is not clear what is the alternative to forcing\nnon-fast-forward push.\n\n> One can easily get in this situation even in a kernel-style workflow:\n> work from your desktop, push, work from your laptop, try to push and it\n> fails.\n\nIMHO, when you often switch between your desktop and laptop, 'matching'\nmakes much more sense. If 'push' fails then usually I want to force non-\nfast-forward push, because the new series contain reworked patches that\nalready were on the other computer.\n\n>\n> Back to my students, most of them will never get in this situation\n> because they won't use branch, so HEAD = master and upstream =\n> origin/master,\n\nSo, there is no real difference between 'current' and 'upstream' for\nthem.\n\n> but the not-so-newbies may get this once they start\n> creating branches ifever they have HEAD = topic-branch and upstream =\n> origin/master for example.\n\nThe real question is what one expects from 'push' in that situation. It\ncould be pushing this branch back to the upstream branch or creating a\nnew feature branch in the upstream.\n\n>\n>> So far a lot of the discussion has focused on \"what is the most sensible\n>> default for the most number of people\". But I wonder if a better\n>> question is \"what is the default that is the least likely to do\n>> something dangerous and embarrassing\".\n>\n> I think \"what's the most intuitive\" is also very important.\n\nBut it depends on the workflow that is employed by the project.\nDifferent projects may have different workflows. We can assume that\nthe person who sets up the repository has good knowledge of Git and\nhow to use it, but many others who work on the same project may not\nknow Git well. For them \"the most intuitive\" means whatever policy\nthis project has.\n\n\nDmitry\n"},{"id":"186897","messageId":"1kgwl7x.5pilu08h6t2eM%lists@haller-berlin.de","threadId":"29881","inReplyTo":"vpqaa3kfwss.fsf@bauges.imag.fr","subject":"Re: Auto-matching upstream branches by name (was: [RFC PATCH] push: start warning upcoming default change for push.default)","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2012-03-13T20:01:49Z","receivedAt":"2012-03-13T20:01:49Z","isPatch":true,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"Matthieu Moy wrote:\n\n> Actually, I'm starting to wonder if the whole \"upstream\" thing should\n> not be deactivated by default, and replaced with a simpler mechanism\n> like \"pull.default\", similar to what \"push.default\" does today. Then,\n> users could set \"pull.default=current\", and \"git pull\" would pull a\n> branch with the same name remotely. Or users could set\n> \"pull.default=upstream\" and get what Git does today.\n\nYes, this is pretty similar to what I had in mind, in the last paragraph\nof this message:\n\n http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694\n\nBut it's not just about pull versus push. If you make them both work\nwith same-name branches automatically, you still need to make \"status\"\nand \"branch -vv\" aware of that too, so that they can report whether you\nare ahead or behind your, well, \"upstream\". \"git log @{u}\" would be\nnice as well in this mode.\n\nSo I think that \"pull.default\" is not the best option to use for this;\nmaybe something like \"branch.automatchupstreambyname\" or some such.\n\n(It's really a separate discussion from the push.default question\nthough, so I'm changing the subject.)\n\n\n-- \nStefan Haller\nBerlin, Germany\nhttp://www.haller-berlin.de/\n"},{"id":"186905","messageId":"20120313213045.GD27436@sigill.intra.peff.net","threadId":"29881","inReplyTo":"7vfwddskon.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-13T21:30:45Z","receivedAt":"2012-03-13T21:30:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 12, 2012 at 12:06:48PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > ... This is not a push.default issue,\n> > but I think it is somewhat related, and maybe worth discussing along\n> > with the topic of asymmetry. ...\n> > I've mostly trained my fingers to type \"git push\n> > \", but I do occasionally forget.\n> \n> In an assymmetric set-up, you would typically push into one place\n> but update from one or more places, so it might make sense to make\n> it easier to say \"git push\" and \"git pull $there\". But that does\n> not solve the fundamental issue, I would think.\n\nI think it can even be a bit more complex than that. For example, I\nactually _never_ run git-pull. Instead, I fetch, and then use the\nupstream config for lots of other operations, like seeing what's in a\ntopic branch, rebasing, etc.\n\nSo to me, it is not just about \"symmetry between push and pull\", but\nthat the upstream config is fundamentally about \"what is this work based\noff of\", which may or may not have anything to do with where you are\npushing to.\n\n> > Do other people with\n> > asymmetric workflows find this annoying? Do they not care? Or are many\n> > fewer people doing asymmetric things than I think?\n> \n> I think it is not \"they do not care\", but \"they do not have a good\n> solution\". I do not think of anything offhand, either.\n\nThe branch.*.pushRemote you mentioned would help with that. But for me,\nI would much rather have simply push.defaultRemote. Configuring each\nbranch independently would be a pain, and I always want to push to my\npublishing point (or at least, by default; anything else is a one-off\nthat can get an option on the command line). It is not a per-branch\nthing at all for me.\n\nSpeaking of which, I often get annoyed at the per-branch\nauto-configuration of upstreams. For example, I find myself doing this:\n\n [get an idea, read a bug report on the list, etc]\n $ cd git\n $ hack hack hack\n [oh, this is turning into something real. Let's make a branch]\n $ git checkout -b jk/bug-fix\n $ git commit -m 'fix bug'\n\nbut now my bug-fix branch is based off of wherever I was (which is\nusually some private topic-integration branch I run most of the time).\nI wish there was some way to say \"No, branches should _always_ consider\norigin/master as their upstream, unless I configure them some other\nway\" (which I do occasionally for building sub-topics on other topics).\n\nWhich makes me wonder if perhaps people are using \"upstream\" to mean\nseveral different thing. I use it to say \"this is the branch that this\ntopic is based off of\", which makes \"git log @{u}..\" helpful, \"git\nrebase -i\" just work, and gives some meaning to the ahead/behind message\n(it shows how my topic relates to the main project).\n\nBut I think people also use upstream to mean \"this is the definitive\nversion of this branch in some central repo\". So they would say that\n\"jk/bug-fix\" is based on \"origin/jk/bug-fix\". And the ahead/behind\nmessage is about \"do I have any local work that needs pushed, or any\nremote work that needs pulled?\"\n\nAnd I wonder if this is where some of the debate for\npush.default=upstream comes from. Whether that is useful to you or not\nwould depend on how you set up your branches. In the latter model, I\nwould think pushing to the upstream would be the right thing.\n\n> Because \"upstream\" is meant to be \"For the branch I am on, you know\n> how the branches map between the remote repository, so you already\n> know what the right thing to do---do it\" mode, the correct \"guess\"\n> in your case is to error out and say \"Nah, you are not talking with\n> your upstream, so I do not have any clue what branches you want to\n> push out and how. As you said that the push.default is upstream, not\n> matching, I refuse to even do the matching push in your case. This\n> is an error. Be more specific\".\n\nYeah, I agree that is the only sane thing to do.\n\n> I do not think \"the most number of people\" is a high-priority issue,\n> but \"least damage\" default may not be necessarily the best.\n> \n> Obviously, \"nothing\" is the least-damage option, and looking at how\n> even people on this list cannot decide between current and upstream,\n> I actually am very tempted to suggest it as the new default.\n\nI was tempted to suggest that, but it somehow feels too overboard and\nunfriendly. I really like \"current\", as it seems like the simplest and\nunsurprising thing we can do, short of doing nothing at all.\n\n-Peff\n"},{"id":"186906","messageId":"20120313213522.GA27752@sigill.intra.peff.net","threadId":"29881","inReplyTo":"7vehswljxi.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-13T21:35:23Z","receivedAt":"2012-03-13T21:35:23Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 13, 2012 at 06:17:13AM -0700, Junio C Hamano wrote:\n\n> Pushing 'current' from a branch 'topic' forked from either 'master'\n> or 'origin/master' will create a new branch 'topic' at the central\n> repository. But that is straightforward and understandable. The user\n> will see what happened in the feedback from the command, and there\n> is no need for the user to be experienced enough to know the mapping\n> of @{upstream} to understand why it happened. \"I am on 'topic' and\n> I pushed, I created 'topic' there\". Very simple explanation exists.\n> [...]\n> That makes me suspect that 'current' might be a more appropriate\n> default between the two. From that simple default, those in the\n> \"shared central repository\" world can graduate to 'upstream' once\n> they know what an 'upstream' is and how to take advantage of\n> per-branch configuration. Similarly, those in the \"publish to be\n> pulled\" world would graduate to 'matching'.\n\nThanks for this explanation. When writing my last email, I had a gut\nfeeling about how \"current\" was a simpler choice, but I didn't quite\nfind the words to explain it. This paragraph (and the rest of the email)\ncovers what I was trying to say.\n\n-Peff\n"},{"id":"186912","messageId":"7v62e8t8m5.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"20120313213045.GD27436@sigill.intra.peff.net","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-13T22:54:26Z","receivedAt":"2012-03-13T22:54:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The branch.*.pushRemote you mentioned would help with that. But for me,\n> I would much rather have simply push.defaultRemote.\n\nI would think that is a natural way to extend it. Don't we already have\nsomething similar that is per repository default that can be overriden\nwith per branch configuration?\n\n> Speaking of which, I often get annoyed at the per-branch\n> auto-configuration of upstreams. For example, I find myself doing this:\n>\n> [get an idea, read a bug report on the list, etc]\n> $ cd git\n> $ hack hack hack\n> [oh, this is turning into something real. Let's make a branch]\n> $ git checkout -b jk/bug-fix\n> $ git commit -m 'fix bug'\n>\n> but now my bug-fix branch is based off of wherever I was (which is\n> usually some private topic-integration branch I run most of the time).\n\nWhat in \"checkout -b jk/bug-fix\" makes jk/bug-fix a downstream of\norigin/master? I admit my brain is not working very well today, but I\nwould have expected the branch to have either your local private topic\nintegration branch as its @{u}, or no @{u} defined for it at all. Perhaps\nthere is a design error of some sort around that code?\n\n> Which makes me wonder if perhaps people are using \"upstream\" to mean\n> several different thing. I use it to say \"this is the branch that this\n> topic is based off of\", which makes \"git log @{u}..\" helpful, \"git\n> rebase -i\" just work, and gives some meaning to the ahead/behind message\n> (it shows how my topic relates to the main project).\n>\n> But I think people also use upstream to mean \"this is the definitive\n> version of this branch in some central repo\". So they would say that\n> \"jk/bug-fix\" is based on \"origin/jk/bug-fix\". And the ahead/behind\n> message is about \"do I have any local work that needs pushed, or any\n> remote work that needs pulled?\"\n\nI think that is the more common interpretation. Earlier you said\nahead/behind gives \"some meaning\", but compared to this \"how many more do\nI have, how many more do others have while I was looking the other way\", I\nam not sure what kind of cue that \"some meaning\" would give us.\n\n> And I wonder if this is where some of the debate for\n> push.default=upstream comes from. Whether that is useful to you or not\n> would depend on how you set up your branches. In the latter model, I\n> would think pushing to the upstream would be the right thing.\n\nNo question about the conclusion in the last sentence, but at the same\ntime, I do not think the push.default is about making things work smoothly\nfor people who configure everything right.\n\n>> Because \"upstream\" is meant to be \"For the branch I am on, you know\n>> how the branches map between the remote repository, so you already\n>> know what the right thing to do---do it\" mode, the correct \"guess\"\n>> in your case is to error out and say \"Nah, you are not talking with\n>> your upstream, so I do not have any clue what branches you want to\n>> push out and how. As you said that the push.default is upstream, not\n>> matching, I refuse to even do the matching push in your case. This\n>> is an error. Be more specific\".\n>\n> Yeah, I agree that is the only sane thing to do.\n\nPerhaps this can be a good sample entry for the experimental \"tracker\"\nthing to keep track of to see how the workflow will evolve around it;\nunless neither of us would get to work on it immediately, it is very\nlikely to be forgotten, as this is a tangent in the overall discussion,\neven though the bug is real and solution is clear.\n"},{"id":"186918","messageId":"7vbonzssap.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"CAHkcotg1FKxfMR4Fe9Xfo_i4nuxzXdfVWe80HZu0wQEkiXhhmA@mail.gmail.com","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-14T04:46:54Z","receivedAt":"2012-03-14T04:46:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Potapov writes:\n\n>> One can easily get in this situation even in a kernel-style workflow:\n>> work from your desktop, push, work from your laptop, try to push and it\n>> fails.\n>\n> IMHO, when you often switch between your desktop and laptop, 'matching'\n> makes much more sense. If 'push' fails then usually I want to force non-\n> fast-forward push, because the new series contain reworked patches that\n> already were on the other computer.\n\nYou are free to live dangerously, but please do not teach that to other\npeople.\n\nSwitching between two machines A and B is done a lot more safely if you\narrange them to cross pull from each other, i.e. on machine A, remotes/B/*\nis where you keep copies of branches of B to with either of these\n\n\tmachineA$ git fetch B refs/heads/*:refs/remotes/B/*\n\tmachineB$ git push A refs/heads/*:refs/remotes/B/*\n\n(the latter is to emulate the former \"fetch\" you wish to run on A to get\ndata from B in the reverse direction), and similarly on machine B, you use\nremotes/A/* to keep copies of branches of A.\n\nThat way, the risk of losing your work because the \"usually\" in your \"then\nusually I want to force\" turns out to be untrue is greatly reduced.\n"},{"id":"186923","messageId":"4F605DD8.9040504@alum.mit.edu","threadId":"29881","inReplyTo":"20120312183725.GA2187@sigill.intra.peff.net","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-03-14T08:59:04Z","receivedAt":"2012-03-14T08:59:04Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/12/2012 07:37 PM, Jeff King wrote:\n> On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote:\n>> * For newbies, the sequence \"create an empty repository, clone it,\n>> commit and push\" works like a charm with either 'upstream' or\n>> 'current'. Today, the first push to an empty repository requires\n>> either saying \"git push origin master\" or \"git push --all\", both of\n>> which sound like black magic to the poor user who did not yet learn\n>> what 'origin' is and what a branch is.\n> \n> Ending that confusion is one of the best reasons to switch the default,\n> IMHO, but I don't think it argues for \"current\" versus \"upstream\", as\n> they both fix it (but Michael's matching-current hybrid would not, so I\n> agree it is less appealing).\n\nIn the case of my proposed matching-current hybrid, the error message\nfor the failing push would make it pretty obvious what went wrong and\nhow to fix it; something like:\n\n $ git push\n The remote repository \"git.example.com:myproject\" does not yet\n contain a branch called \"master\". If you would like to create one\n now, type\n\n git push origin master\n\n For other alternatives, please see gitworkflows(7).\n\nThis error message would appear *whenever* the matching-current hybrid\npolicy caused the push to fail. Since this problem occurs only if (1)\nthe upstream repository is empty and (2) the user hasn't configured a\nmore liberal global push.default, and since it is blindingly obvious\nwhat to do to fix the problem, it doesn't seem especially onerous.\n\n(One could even create a special-case to allow such a push when the\nupstream repository is empty, but I don't think the gain in convenience\nis worth the loss of consistency.)\n\n> So far a lot of the discussion has focused on \"what is the most sensible\n> default for the most number of people\". But I wonder if a better\n> question is \"what is the default that is the least likely to do\n> something dangerous and embarrassing\". People who use git enough to say\n> \"wow, I don't like this default for my workflow\" are probably at the\n> point that they can configure push.default themselves.\n\nI agree entirely. And here is an algorithm for deciding what the\ndefault should be:\n\n1. Make a list of branch configurations that can be distinguished by\n git, which would be something like all combinations of\n\n * remote has a branch with the same name as the current branch?\n * no\n * yes, and remote branch could be fast-forwarded to local state\n * yes, but remote branch cannot be fast-forwarded to local state\n\n * local branch has known upstream branch on remote?\n * no\n * yes, and remote upstream branch could be fast-forwarded to\n the state of the current local branch\n * yes, but remote upstream branch cannot be fast-forwarded to\n the state of the current local branch\n\n2. In each of these situations, decide what \"git push\" should do in\n each of the common workflows.\n\n3. In the branching configurations for which all workflows agree about\n what \"git push\" should do, then that is what \"git push\" should do by\n default. When they do not agree, then \"git push\" should do nothing,\n give an informative error message, and leave it to the user to\n decide. If all workflows agree on a safe subset of what \"git push\"\n should do (for example, \"matching\" and \"current\" agree that the\n current branch should be pushed even though they disagree whether\n other branches should be pushed), then it might be OK to carry out\n the safe subset.\n\nThe most common workflows, along with the configuration settings that\nare recommended for that workflow, should be given standard names and\ndocumented in gitworkflows(7). The warning message for a failed \"git\npush\" invocations (especially if push.default is unset) should direct\nthe user to this manpage.\n\n\nIsn't it obvious?: The fact that we cannot even agree among ourselves\nwhat \"git push\" should do in all cases *proves* that we are trying to be\ntoo ambitious with DWIM. \"git push\" must therefore become more\ndeferential when the obvious thing to do is unclear, especially given\nthat mistakes (due to the very nature of \"git push\") often have\nembarrassing and publicly visible effects.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"186925","messageId":"vpqhaxrzh2a.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"CAHkcotg1FKxfMR4Fe9Xfo_i4nuxzXdfVWe80HZu0wQEkiXhhmA@mail.gmail.com","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-14T09:07:41Z","receivedAt":"2012-03-14T09:07:41Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Dmitry Potapov writes:\n\n> On Tue, Mar 13, 2012 at 1:34 PM, Matthieu Moy\n> wrote:\n>> Jeff King writes:\n>>\n>>>   1. If you are a new user who does like the implicit merge, you may\n>>>      find it convenient not to have to learn about \"git checkout; git\n>>>      merge topic ; git push remote master\". But it only helps you\n>>>      _sometimes_. If master has had other work built on it, your push\n>>>      will fail, and you will have to do the merge yourself. So it is\n>>>      only helping you by omitting a step some of the time, and you still\n>>>      have to learn why the step is sometimes necessary and sometimes\n>>>      not.\n>>\n>> There's a rule of thumb which works very well for beginners: when \"git\n>> push\" tells you to pull before, then pull before. This rule of thumb\n>> works, but only provided \"push\" and \"pull\" are symmetrical.\n>\n> I am not sure what you mean by symmetrical here, because they are never\n> truly symmetrical as \"pull\" does merge and \"push\" does not.\n\nI mean \"they work with the same branch\".\n\n> If there is a centralized workflow with only one branch then\n> everything is simple, but it is not so with other workflows.\n\nI don't get this. With either 'current' or 'upstream', both pull and\npush deal with one local and one remote branch. The only asymetry is the\ncase of non-fast forward (push fails, pull merges). But it's all about\ntransmitting changes from a branch to another, in one or another\ndirection.\n\n> Moreover, doing 'git pull' too often (unless it is 'git pull --rebase)\n> pollutes history with useless merges, making more difficult to review\n> changes, or doing git-bisect.\n\nWhat's your point here? How does it invalidate the rule of thumb above?\n\nWhether you want to pull often or not, it does not change the fact that\nyou cannot do non-fast forward push (at least, not without losing\nhistory). If the user tried to push, what would you suggest if not\npulling (or merging in whatever way you want)? Blame the user who wanted\nto push that he shouldn't have tried that?\n\n> I agree that the current diagnostic is not suitable for beginners.\n> Not-fast-forward push is something that beginners should never use,\n> but from this message is not clear what is the alternative to forcing\n> non-fast-forward push.\n\nAgain, what would you suggest? Teach --force to beginners?\n\n>> One can easily get in this situation even in a kernel-style workflow:\n>> work from your desktop, push, work from your laptop, try to push and it\n>> fails.\n>\n> IMHO, when you often switch between your desktop and laptop, 'matching'\n> makes much more sense.\n\nThen, if you worked on branch 'foo' from your desktop, and 'bar' on your\nlaptop, you'll get errors about non-fast forward push from both machines.\n\n> If 'push' fails then usually I want to force non- fast-forward push,\n> because the new series contain reworked patches that already were on\n> the other computer.\n\n... but if they were not, you've just silently errased your previous\nwork. I have no problem with you working like this, but please don't\nteach that to beginners.\n\n>> but the not-so-newbies may get this once they start\n>> creating branches ifever they have HEAD = topic-branch and upstream =\n>> origin/master for example.\n>\n> The real question is what one expects from 'push' in that situation. It\n> could be pushing this branch back to the upstream branch or creating a\n> new feature branch in the upstream.\n\nYes. But both of them are covered by 'push.default=upstream', depending\non how you configured the upstream.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186926","messageId":"vpq8vj3zgwz.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"1kgwl7x.5pilu08h6t2eM%lists@haller-berlin.de","subject":"Re: Auto-matching upstream branches by name","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-14T09:10:52Z","receivedAt":"2012-03-14T09:10:52Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"lists@haller-berlin.de (Stefan Haller) writes:\n\n> Matthieu Moy wrote:\n>\n>> Actually, I'm starting to wonder if the whole \"upstream\" thing should\n>> not be deactivated by default, and replaced with a simpler mechanism\n>> like \"pull.default\", similar to what \"push.default\" does today. Then,\n>> users could set \"pull.default=current\", and \"git pull\" would pull a\n>> branch with the same name remotely. Or users could set\n>> \"pull.default=upstream\" and get what Git does today.\n>\n> Yes, this is pretty similar to what I had in mind, in the last paragraph\n> of this message:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694\n\nIndeed, yes.\n\n> But it's not just about pull versus push. If you make them both work\n> with same-name branches automatically, you still need to make \"status\"\n> and \"branch -vv\" aware of that too, so that they can report whether you\n> are ahead or behind your, well, \"upstream\". \"git log @{u}\" would be\n> nice as well in this mode.\n>\n> So I think that \"pull.default\" is not the best option to use for this;\n> maybe something like \"branch.automatchupstreambyname\" or some such.\n\nI'd call that 'upstream.default' actually.\n\n> (It's really a separate discussion from the push.default question\n> though, so I'm changing the subject.)\n\nSeparate, but related. If Git had this behavior as default, I'd\nrecommend 'current' without hesitation. I'm starting to be convinced\nthat the whole 'upstream' stuff is confusing for non-expert, but it is\nfor pull as much as it is for push.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186933","messageId":"CAFsnPqrU7fzybncyhY35iAjjQWpAiW_Y2YAW8ExP6Qrxfbu_Cw@mail.gmail.com","threadId":"29881","inReplyTo":"201203131627.30455.jnareb@gmail.com","subject":"Re: git push default behaviour?","fromName":"Jeremy Morton","fromEmail":"jeremy@configit.com","sentAt":"2012-03-14T12:12:48Z","receivedAt":"2012-03-14T12:12:48Z","isPatch":false,"sender":{"key":"jeremy@configit.com","avatar":null},"body":"Would that deny non fast-forwards for all branches, though, or just\nselected ones? We'd like to just to it for 2 of our branches. We'd\nalso like to explitly ALLOW fast-forwards to master, when we want to\nmerge in from develop to master.\n\nA better description of what we want is to prevent 'rewriting of\nhistory' for some of our branches.\n\nBest regards,\nJeremy Morton (Jez)\n\nOn Tue, Mar 13, 2012 at 4:27 PM, Jakub Narebski wrote:\n> On Thu, 8 Mar 2012, Jeremy Morton wrote:\n>> On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski wrote:\n>\n>> > You can always configure server to refuse forced pushes.\n>>\n>> We're using github, and as far as I'm aware, there's no way to\n>> configure github to do that.\n>\n> It would be nice if GitHub supported setting receive.denyNonFastForward\n> and receive.denyDeletes (the receive.*current* do not matter for GitHub).\n> Though I am not sure if it would not require changes to the custom Git\n> implementation they use...\n>\n> --\n> Jakub Narebski\n> Poland\n"},{"id":"186936","messageId":"CAHkcotgsU6XZCTB+YKKeVMsUC2Yr5pVoc7eJpxdyH-GcxzeTVw@mail.gmail.com","threadId":"29881","inReplyTo":"7vbonzssap.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2012-03-14T12:47:34Z","receivedAt":"2012-03-14T12:47:34Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Mar 14, 2012 at 8:46 AM, Junio C Hamano wrote:\n> Dmitry Potapov writes:\n>\n>>> One can easily get in this situation even in a kernel-style workflow:\n>>> work from your desktop, push, work from your laptop, try to push and it\n>>> fails.\n>>\n>> IMHO, when you often switch between your desktop and laptop, 'matching'\n>> makes much more sense. If 'push' fails then usually I want to force non-\n>> fast-forward push, because the new series contain reworked patches that\n>> already were on the other computer.\n>\n> You are free to live dangerously, but please do not teach that to other\n> people.\n\nIs it more dangerous than using \"git reset --hard somewhere\" ?\nI believe both cases I should be able to recover the lost using reflog.\nAnyway, so far I have never had any problem, because I do \"git push\"\nfirst and then look at failures and decide whether I want to discard\nthe old series on the remote end.\n\n> Switching between two machines A and B is done a lot more safely if you\n> arrange them to cross pull from each other, i.e. on machine A, remotes/B/*\n> is where you keep copies of branches of B to with either of these\n>\n>        machineA$ git fetch B refs/heads/*:refs/remotes/B/*\n>        machineB$ git push A refs/heads/*:refs/remotes/B/*\n>\n> (the latter is to emulate the former \"fetch\" you wish to run on A to get\n> data from B in the reverse direction), and similarly on machine B, you use\n> remotes/A/* to keep copies of branches of A.\n\nI am aware about that, but the thing that stops me from using this is\nthere is no way to delete automatically all references from the remote\nend that were deleted locally. (There is --mirror option, which can do\nthis, but it is incompatible with refspecs)\n\nIf I use only \"git fetch B ...\", I can run \"git remote prune B\" from time\nto time to remove branches that no longer exists on B. However, if I do\n\"git push A ...\" as you suggested then A will accumulate old garabage\nfrom B very quickly.\n\n\nDmitry\n"},{"id":"186939","messageId":"CAHkcotgMgqr29WEQfiH+89JVbTAAQyLwscXRtTyrf3JRxEuVbA@mail.gmail.com","threadId":"29881","inReplyTo":"vpqhaxrzh2a.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2012-03-14T13:23:33Z","receivedAt":"2012-03-14T13:23:33Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Mar 14, 2012 at 1:07 PM, Matthieu Moy\n wrote:\n> Dmitry Potapov writes:\n>\n>> If there is a centralized workflow with only one branch then\n>> everything is simple, but it is not so with other workflows.\n>\n> I don't get this. With either 'current' or 'upstream', both pull and\n> push deal with one local and one remote branch. The only asymetry is the\n> case of non-fast forward (push fails, pull merges). But it's all about\n> transmitting changes from a branch to another, in one or another\n> direction.\n\nIf a user has 'master' after cloning and then create another branch\nwith different names, are you sure that the user expects that this\nsecond branch to be pushed to a remote 'master'? And then what about\nhis stale local 'master'?\n\nThose who understand the concept tracking may be happy with 'upstream'\nbut when it comes to the least surprise principle for beginner , I\nbelieve 'current' is better. Maybe it would be even better if it did\nnot create a new remote branch without asking first:\n\nStaying on foo-branch, you do:\n $ git push\nWarning: foo-branch does not exist on the remote, if you want to\ncreate it, type: \"git push foo-branch\"\n\nIn this way, it will be safer.\n\n>\n>> Moreover, doing 'git pull' too often (unless it is 'git pull --rebase)\n>> pollutes history with useless merges, making more difficult to review\n>> changes, or doing git-bisect.\n>\n> What's your point here? How does it invalidate the rule of thumb above?\n\nThe point is that you still need to understand what you are doing. It\nis not 'pull' magically resolve the problem. On the other hand, if you\nreally want a workflow similar to CVS then you need \"git pull --rebase\"\n(you can configure 'pull' to do rebase by default, but beginners do not\nknow about it).\n\nBTW, whether you do merge or rebase, you still need to test the result\nbefore pushing. Even if there was no conflicts, it may not work anymore.\nAnd while you are merging and testing everything, somebody else could\npush his changes. So, a centralized workflow may appear simple, but it\ndoes not scale well, and often leads to many untested and hastily merged\ncommits.\n\n>> I agree that the current diagnostic is not suitable for beginners.\n>> Not-fast-forward push is something that beginners should never use,\n>> but from this message is not clear what is the alternative to forcing\n>> non-fast-forward push.\n>\n> Again, what would you suggest? Teach --force to beginners?\n\nNot of course. I said above non-fast forward push should not be used by\nbeginners. However, if you have branches and merge them (using 'pull' or\n'merge'), it is silly pretend that they do not exist. If you happy with\nCVS-like behavior then just do \"pull --rebase\".\n\n>\n>>> One can easily get in this situation even in a kernel-style workflow:\n>>> work from your desktop, push, work from your laptop, try to push and it\n>>> fails.\n>>\n>> IMHO, when you often switch between your desktop and laptop, 'matching'\n>> makes much more sense.\n>\n> Then, if you worked on branch 'foo' from your desktop, and 'bar' on your\n> laptop, you'll get errors about non-fast forward push from both machines.\n\nRight... and then I look at the cause, and usually I have made some\nminor fixes to some series of patches. So when I make my mind, I do\nnon-fast forward push, but I do not think it is how beginners should\nstart to use 'git'.\n\n>\n>> If 'push' fails then usually I want to force non- fast-forward push,\n>> because the new series contain reworked patches that already were on\n>> the other computer.\n>\n> ... but if they were not, you've just silently errased your previous\n> work. I have no problem with you working like this, but please don't\n> teach that to beginners.\n\nBasically, it is same as doing 'git reset --hard somewhere'. I use it\nsometimes, but I have never suggested that for beginners...\n\n\nDmitry\n"},{"id":"186941","messageId":"20120314135009.GA934@sigill.intra.peff.net","threadId":"29881","inReplyTo":"7v62e8t8m5.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-14T13:50:10Z","receivedAt":"2012-03-14T13:50:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 13, 2012 at 03:54:26PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > The branch.*.pushRemote you mentioned would help with that. But for me,\n> > I would much rather have simply push.defaultRemote.\n> \n> I would think that is a natural way to extend it. Don't we already have\n> something similar that is per repository default that can be overriden\n> with per branch configuration?\n\nI think branch.*.rebase / pull.rebase is the only current example. But\nyeah, having a hierarchy like that makes sense to me.\n\n> > Speaking of which, I often get annoyed at the per-branch\n> > auto-configuration of upstreams. For example, I find myself doing this:\n> >\n> > [get an idea, read a bug report on the list, etc]\n> > $ cd git\n> > $ hack hack hack\n> > [oh, this is turning into something real. Let's make a branch]\n> > $ git checkout -b jk/bug-fix\n> > $ git commit -m 'fix bug'\n> >\n> > but now my bug-fix branch is based off of wherever I was (which is\n> > usually some private topic-integration branch I run most of the time).\n> \n> What in \"checkout -b jk/bug-fix\" makes jk/bug-fix a downstream of\n> origin/master? I admit my brain is not working very well today, but I\n> would have expected the branch to have either your local private topic\n> integration branch as its @{u}, or no @{u} defined for it at all. Perhaps\n> there is a design error of some sort around that code?\n\nSorry, reading my example again, I was completely unclear. I was trying\nto simplify it down to a readable case and ended up omitting the parts\nthat would have it make any sense. So let me try again:\n\nI play around with a fix or a feature on top of some random branch.\nEventually, I realize that this is a promising direction, and want to\nmake a topic branch. I'm in a state where I have some work-in-progress\ncommits on top of a random point (which yes, means my commits might be\ntotally bogus when ported to origin/master, but in practice, they are\nclose enough).\n\nOne option would be:\n\n $ git checkout -b jk/bug-fix origin/master\n $ git cherry-pick @{-1}~2..@{-1}\n\nwhich sets up the upstream appropriately. But what I often end up doing\nis:\n\n $ git checkout -b jk/bug-fix\n $ git rebase -i --onto origin/master HEAD~2\n\nto tweak the patch ordering. Or even:\n\n $ git checkout -b jk/bug-fix\n $ hack hack hack\n [oops, this should be based on master, not where I was]\n $ git rebase --onto origin/master HEAD~2\n\nIn all three cases, I end up in the same state of history, but only in\nthe first one is my upstream config even remotely useful. There are\nother variants, too, where I use \"stash\" and \"reset\" to end up building\non the history I want.\n\nTwo caveats before I go further:\n\n 1. You might argue that the real problem is that I'm building the\n tentative change somewhere inappropriate. And that is kind of true,\n and this could all be averted by running \"git checkout\" in the\n first place to build on the appropriate spot. Though I do sometimes\n do that, too:\n\n $ git checkout origin/master\n $ test test test\n [ok, bug exists]\n $ fix fix fix\n [ok, this is worth a topic branch]\n $ git checkout -b jk/bug-fix\n\n and it also does not set up the upstream config. It would if I used\n a local \"master\" branch, but I do not have one (and I do not want\n one, as it would just be a pain to keep in sync with\n origin/master).\n\n 2. I really just want everything based off of origin/master, because\n that is an implicit part of my workflow for this project. So I am\n not arguing that what \"git checkout -b\" does is wrong given the\n information I have given git, but that there is no place for me to\n give git that information.\n\nSo originally, I had a vague notion in my mind that I wanted some way to\ntell \"no, really, I always want to think of origin/master as the\nupstream unless I explicitly tell you otherwise\". Something like:\n\n $ git config branch.defaultUpstream refs/remotes/origin/master\n $ git config branch.autosetupmerge false\n\nBut having just typed out several examples, I think git _could_ figure\nthis out automatically. My real complaint is that as I use lower-level\ntools to adjust the basis of my history, the upstream config is not\nsimilarly updated. So another option would be:\n\n 1. git-rebase could re-adjust the upstream config when using \"--onto\"\n with a branch parameter.\n\n 2. git-reset could re-adjust the upstream config when moving directly\n to a branch.\n\n 3. When we detach HEAD, remember the original branch name (in\n .git/ORIGINAL_BRANCH or similar); when a branch is created from\n the detached HEAD, set up ORIGINAL_BRANCH as the upstream. You'd\n probably want the \"rebase\" and \"reset\" in steps (1) and (2) to\n update ORIGINAL_BRANCH when you're on a detached HEAD.\n\nI think that would perfectly fit my workflow. But I'm not sure if other\npeople would be confused by these operations changing the upstream\nconfig (e.g., if you expect \"jk/bug-fix\" to have an upstream of\n\"origin/jk/bug-fix\", when such a change would not be welcome).\n\n> > But I think people also use upstream to mean \"this is the definitive\n> > version of this branch in some central repo\". So they would say that\n> > \"jk/bug-fix\" is based on \"origin/jk/bug-fix\". And the ahead/behind\n> > message is about \"do I have any local work that needs pushed, or any\n> > remote work that needs pulled?\"\n> \n> I think that is the more common interpretation. Earlier you said\n> ahead/behind gives \"some meaning\", but compared to this \"how many more do\n> I have, how many more do others have while I was looking the other way\", I\n> am not sure what kind of cue that \"some meaning\" would give us.\n\nIf upstream is \"here is where my topic is based from\", then the\nahead/behind tells you how big your topic is (ahead), and whether it\nmight be a candidate for rebasing (behind). If your upstream is \"the\ncentral repo version of topic\", then it tells you what work you have yet\nto share with others (ahead), and what work others have done on the\ntopic that you could merge (behind).\n\n> >> Because \"upstream\" is meant to be \"For the branch I am on, you know\n> >> how the branches map between the remote repository, so you already\n> >> know what the right thing to do---do it\" mode, the correct \"guess\"\n> >> in your case is to error out and say \"Nah, you are not talking with\n> >> your upstream, so I do not have any clue what branches you want to\n> >> push out and how. As you said that the push.default is upstream, not\n> >> matching, I refuse to even do the matching push in your case. This\n> >> is an error. Be more specific\".\n> >\n> > Yeah, I agree that is the only sane thing to do.\n> \n> Perhaps this can be a good sample entry for the experimental \"tracker\"\n> thing to keep track of to see how the workflow will evolve around it;\n> unless neither of us would get to work on it immediately, it is very\n> likely to be forgotten, as this is a tangent in the overall discussion,\n> even though the bug is real and solution is clear.\n\nI agree this is a candidate for that. But this is where the concept of\nthe tracker breaks down. Who is supposed to update it? You or me? Some\nvolunteer who agrees to migrate email discussion into the tracker? I\nsuspect the latter will not work for a point buried so deeply in a\nthread. Which leaves you and me.\n\nI specifically stayed out of the tracker discussion this time around\nbecause all I had to contribute was \"please no, web-based tools are an\nabomination\". But now that we see a potential use-case in practice, I am\nrealizing that I would not mind at all making a note in a todo file, or\neven sending an email. But the thought of filling out a structured\nproblem report to go into a web-based database makes me not want to\nbother. Perhaps it is just my natural curmudgeonliness, but I think\npart of it is that I know I am unlikely to actually visit the page to\never retrieve the information.\n\nI dunno.\n\n-Peff\n"},{"id":"186942","messageId":"20120314140012.GA2651@sigill.intra.peff.net","threadId":"29881","inReplyTo":"4F605DD8.9040504@alum.mit.edu","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-14T14:00:12Z","receivedAt":"2012-03-14T14:00:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 14, 2012 at 09:59:04AM +0100, Michael Haggerty wrote:\n\n> > Ending that confusion is one of the best reasons to switch the default,\n> > IMHO, but I don't think it argues for \"current\" versus \"upstream\", as\n> > they both fix it (but Michael's matching-current hybrid would not, so I\n> > agree it is less appealing).\n> \n> In the case of my proposed matching-current hybrid, the error message\n> for the failing push would make it pretty obvious what went wrong and\n> how to fix it; something like:\n> \n> $ git push\n> The remote repository \"git.example.com:myproject\" does not yet\n> contain a branch called \"master\". If you would like to create one\n> now, type\n> \n> git push origin master\n> \n> For other alternatives, please see gitworkflows(7).\n> \n> This error message would appear *whenever* the matching-current hybrid\n> policy caused the push to fail. Since this problem occurs only if (1)\n> the upstream repository is empty and (2) the user hasn't configured a\n> more liberal global push.default, and since it is blindingly obvious\n> what to do to fix the problem, it doesn't seem especially onerous.\n\nThanks for the clarification. That does go a long way towards dealing\nwith the confusion. I think I'd be OK with that, though I am on the\nfence about whether just pushing (i.e., \"current\") would be better or\nworse.\n\n> 3. In the branching configurations for which all workflows agree about\n> what \"git push\" should do, then that is what \"git push\" should do by\n> default. When they do not agree, then \"git push\" should do nothing,\n> give an informative error message, and leave it to the user to\n> decide.\n> [...]\n> Isn't it obvious?: The fact that we cannot even agree among ourselves\n> what \"git push\" should do in all cases *proves* that we are trying to be\n> too ambitious with DWIM. \"git push\" must therefore become more\n> deferential when the obvious thing to do is unclear, especially given\n> that mistakes (due to the very nature of \"git push\") often have\n> embarrassing and publicly visible effects.\n\nI find your approach interesting, but it doesn't deal with one problem:\nuser perception when git fails to do something out of the box. I am\nworried that the rule above means that push will end up defaulting to\nnothing. It is one thing to say \"there are so many workflows, and they\ndo not agree, so we should be safe and do nothing\"; that makes sense to\nan advanced user who thinks about things like different workflows. But\nto a brand-new git user who is running \"push\" in their first session, it\nmakes git seem very unfriendly.\n\nAnd that's why I think either \"current\" or \"current-if-matching\" as you\ndescribe is a sane default. I don't think it matches with what the\n\"upstream\" people want, and so does not meet your criteria above as a\ndefault behavior. But it does something sensible and not very dangerous\nor embarrassing, and it means git will do something that is probably\nuseful out of the box for a new user.\n\n-Peff\n"},{"id":"186950","messageId":"vpqhaxrz1c6.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"CAHkcotgMgqr29WEQfiH+89JVbTAAQyLwscXRtTyrf3JRxEuVbA@mail.gmail.com","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-14T14:47:21Z","receivedAt":"2012-03-14T14:47:21Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Dmitry Potapov writes:\n\n> Not of course. I said above non-fast forward push should not be used by\n> beginners.\n\nDo you mean \"beginners should not force non-fast forward push\", or\n\"beginners should not use flow where push may be denied because of\nnon-fast forward\"?\n\nIf the second, this implies that beginners should never have a shared\nrepository, either shared for one user and multiple machines, or shared\nbetween developers?\n\nIf you mean that shared repositories are too complex for beginners, my\nexperience is exactly the opposite.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"186966","messageId":"201203141816.07080.jnareb@gmail.com","threadId":"29881","inReplyTo":"CAFsnPqrU7fzybncyhY35iAjjQWpAiW_Y2YAW8ExP6Qrxfbu_Cw@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-14T17:16:06Z","receivedAt":"2012-03-14T17:16:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Could you please do not top-post? TIA.\n\nJeremy Morton wrote:\n> On Tue, Mar 13, 2012 at 4:27 PM, Jakub Narebski wrote:\n> > On Thu, 8 Mar 2012, Jeremy Morton wrote:\n> >> On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski wrote:\n> >\n> >> > You can always configure server to refuse forced pushes.\n> >>\n> >> We're using github, and as far as I'm aware, there's no way to\n> >> configure github to do that.\n> >\n> > It would be nice if GitHub supported setting receive.denyNonFastForward\n> > and receive.denyDeletes (the receive.*current* do not matter for GitHub).\n> > Though I am not sure if it would not require changes to the custom Git\n> > implementation they use...\n>\n> Would that deny non fast-forwards for all branches, though, or just\n> selected ones? We'd like to just to it for 2 of our branches. We'd\n> also like to explitly ALLOW fast-forwards to master, when we want to\n> merge in from develop to master.\n\nNo, receive.denyNonFastForward is for all branches only. If you want\nper-branch access control, try gitolite... again not available on GitHub\n(unless GitHub allows custom hooks).\n \n> A better description of what we want is to prevent 'rewriting of\n> history' for some of our branches.\n\nC.f. http://thread.gmane.org/gmane.comp.version-control.git/189895\n http://thread.gmane.org/gmane.comp.version-control.git/189946/focus=191119\n\nThough that is only a proposal and a prototype.\n-- \nJakub Narebski\nPoland\n"},{"id":"186968","messageId":"7vpqcfqefy.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"CAHkcotgsU6XZCTB+YKKeVMsUC2Yr5pVoc7eJpxdyH-GcxzeTVw@mail.gmail.com","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-14T17:29:05Z","receivedAt":"2012-03-14T17:29:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Potapov writes:\n\n> ... However, if I do\n> \"git push A ...\" as you suggested then A will accumulate old garabage\n> from B very quickly.\n\nThat is not a valid excuse, is it?\nIt only shows that lack of \"push --prune A\" is a problem to be solved.\n\nAnd hasn't it been solved already?\n"},{"id":"186970","messageId":"CAHkcothjDBP+cyGRf--mNgwF5Sp2UiR3Gq1Vb-XwsKmMH_JCvA@mail.gmail.com","threadId":"29881","inReplyTo":"vpqhaxrz1c6.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2012-03-14T17:47:23Z","receivedAt":"2012-03-14T17:47:23Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Mar 14, 2012 at 6:47 PM, Matthieu Moy\n wrote:\n> Dmitry Potapov writes:\n>\n>> Not of course. I said above non-fast forward push should not be used by\n>> beginners.\n>\n> Do you mean \"beginners should not force non-fast forward push\", or\n> \"beginners should not use flow where push may be denied because of\n> non-fast forward\"?\n\nOf course, the former. I have never said that the centralized workflow\nshould never been used. I have only said that it is not scalable and\nlead to problems in larger projects.\n\n> If the second, this implies that beginners should never have a shared\n> repository,\n\nWell, you can set up a shared repository where everyone has their own\nnamespaces to push. I don't say that that it is better than having one\npublic repository per user, but it may be easier to setup...\n\nSo it only implies that you cannot have a centralized workflow in this\nway.\n\n> either shared for one user and multiple machines, or shared\n> between developers?\n\nI am not sure that I understood this part.\n\n> If you mean that shared repositories are too complex for beginners, my\n> experience is exactly the opposite.\n\nIt is not too complex but it is wrong for any more or less serious project.\nGit is flexible enough to cover different workflows, including some variant\nof a centralized workflow, but git was not designed with the centralized\nworkflow in mind. So some trade-offs are different in it than in VCS that\nwere designed primary (if not only) to be used with a centralized workflow.\nIMHO if you teach git then you should teach a distributed workflow,\nbecause it is the workflow where advantages of git is most obvious...\n\nDmitry\n"},{"id":"186971","messageId":"CAHkcotimwxg3aRxYzHx-3a1THsc=oX83qrmGswZVJnKa3R86ww@mail.gmail.com","threadId":"29881","inReplyTo":"7vpqcfqefy.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2012-03-14T17:49:15Z","receivedAt":"2012-03-14T17:49:15Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Mar 14, 2012 at 9:29 PM, Junio C Hamano wrote:\n> Dmitry Potapov writes:\n>\n>> ... However, if I do\n>> \"git push A ...\" as you suggested then A will accumulate old garabage\n>> from B very quickly.\n>\n> That is not a valid excuse, is it?\n\nMaybe not, but so far I have never had any problem with the way I use now.\nSo I have not had any real insensitive to change that. Though I agree that\nwhat you proposed is better except pruning deleted branches.\n\n> It only shows that lack of \"push --prune A\" is a problem to be solved.\n>\n> And hasn't it been solved already?\n>\n\nHas it? Somehow I cannot find the corresponding option in the manual.\nWhat did I miss?\n\nDmitry\n"},{"id":"186982","messageId":"4F60EE4B.9020803@ira.uka.de","threadId":"29881","inReplyTo":"7v7gyoxuth.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-03-14T19:15:23Z","receivedAt":"2012-03-14T19:15:23Z","isPatch":true,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 13.03.2012 18:41, Junio C Hamano wrote:\n> Holger Hellmuth writes:\n>> If Peff's \"push to same branch in a different remote\" is a bug (and\n>> IMHO it is) it should not count as a reason for what should be the\n>> default.\n>\n> I may phrased it poorly, but I don't think you mean \"if the bug is fixed,\n> then the behaviour of upstream is simple and easy to understand\". The\n\nI think the behaviour of the whole pull/push system is not easy to \nunderstand. One has to learn a lot of concepts about git before being \nable to answer the simple question \"if I do 'git push' now, what happens?\".\n\nSince I am using git without any collaboration I never had much need to \nplay around with the whole porcelain remote configuration (cloning and \nusing git config was enough). So today I tried to create a bidirectional \nlink between a local and a remote branch using only porcelain commands \n(i.e. without using git config directly). Somehow I didn't succeed. I \ncan either use git checkout --track or git push -u to make a pull \nconnection between the two, but to automatically push I would have to \ncreate a branch of the same name (and know that this is the magical \ningredient that makes it work!)\n\nMaybe what is missing is a parameter to git-push that tells git that \nfrom now on this is what git push should do per default in this branch \n(Similar to what git checkout --track does). This would mean that even \nnew users could do most remote configuration with just the knowledge of \ngit checkout and git push.\n\nBy the way I think I found another \"hole\" in the porcelain: If you add a \nsingle branch to follow with git remote add -t ..., you can't \nadd another. A second git remote add -t ... will be met \nwith an error that the remote is already configured. I would have to \ndelete the remote and add it again with git add -t -t \n ..... Or use a different remote name (which would be \nconfusing later on). Did I miss something?\n"},{"id":"186992","messageId":"7vwr6moqtu.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"CAHkcotimwxg3aRxYzHx-3a1THsc=oX83qrmGswZVJnKa3R86ww@mail.gmail.com","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-14T20:44:29Z","receivedAt":"2012-03-14T20:44:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Potapov writes:\n\n>> It only shows that lack of \"push --prune A\" is a problem to be solved.\n>>\n>> And hasn't it been solved already?\n>\n> Has it? Somehow I cannot find the corresponding option in the manual.\n> What did I miss?\n\nWhat you are missing is that you are not running 1.7.10-rc to help shaking\nout last minute regressions.\n\nPlease be a good resident on this list and help us out ;-)\n"},{"id":"186993","messageId":"7vsjhaoq4q.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"20120314135009.GA934@sigill.intra.peff.net","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-14T20:59:33Z","receivedAt":"2012-03-14T20:59:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Two caveats before I go further:\n>\n> 1. You might argue that the real problem is that I'm building the\n> tentative change somewhere inappropriate.\n\nNo, that is completely normal for a developer to start into one direction\nand then later realize something and change his course. In fact, many\nparts of Git strive to help you avoid being bound by premature commitments\n(e.g. \"checkout [-m] \" takes local changes with you). I think\nthis discussion is only showing that the @{upstream} part wasn't as\ncarefully designed as other parts of the system.\n\n> 2. I really just want everything based off of origin/master, because\n> that is an implicit part of my workflow for this project.\n\nI think this probably shows that \"autosetupmerge\" mechanism is not\npolished enough. Perhaps it can take, in addition to \"true/false\", a ref\nin refs/remotes namespace, or something. If you have \"these branches are\nto be off of this, this other set of branches are to be off of that\", it\nmay need to become more elaborate.\n\n> I think that would perfectly fit my workflow. But I'm not sure if other\n> people would be confused by these operations changing the upstream\n> config (e.g., if you expect \"jk/bug-fix\" to have an upstream of\n> \"origin/jk/bug-fix\", when such a change would not be welcome).\n\nYeah, the above is starting to sound a bit overengineered black magic.\n\n>> Perhaps this can be a good sample entry for the experimental \"tracker\"\n>> thing to keep track of to see how the workflow will evolve around it;\n>> unless neither of us would get to work on it immediately, it is very\n>> likely to be forgotten, as this is a tangent in the overall discussion,\n>> even though the bug is real and solution is clear.\n\nHeh, I find myself already forgetting what this \"clear bug\" was and having\nto look up in your message (the issue is \"git push $there\" when $there\ndoes not match branch.$current.remote, it should error out).\n\n> I agree this is a candidate for that. But this is where the concept of\n> the tracker breaks down. Who is supposed to update it? You or me? Some\n> volunteer who agrees to migrate email discussion into the tracker? I\n> suspect the latter will not work for a point buried so deeply in a\n> thread. Which leaves you and me.\n\nThat is why I think any demand (I wouldn't call it \"proposal\" or\n\"suggestion\") to this project to use tracker fundamentally is flawed.\n\n> I specifically stayed out of the tracker discussion this time around\n> because all I had to contribute was \"please no, web-based tools are an\n> abomination\". But now that we see a potential use-case in practice, I am\n> realizing that I would not mind at all making a note in a todo file, or\n> even sending an email. But the thought of filling out a structured\n> problem report to go into a web-based database makes me not want to\n> bother.\n\nI agree with this 100%. If it takes more than just adding an email\naddress to Cc: line to either a tracker bot or a human project secretary,\nI cannot be bothered to spend extra 10 minutes to go to an extra web site,\nlog-in and fill the form fields.\n"},{"id":"187025","messageId":"vpqehsumgvd.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"4F60EE4B.9020803@ira.uka.de","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-15T08:02:30Z","receivedAt":"2012-03-15T08:02:30Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Holger Hellmuth writes:\n\n> So today I tried to create a\n> bidirectional link between a local and a remote branch using only\n> porcelain commands (i.e. without using git config directly). Somehow I\n> didn't succeed. I can either use git checkout --track or git push -u\n> to make a pull connection between the two, but to automatically push I\n> would have to create a branch of the same name (and know that this is\n> the magical ingredient that makes it work!)\n\nIn this particular case, having 'push.default=upstream' would have done\nit for you: your \"push -u\" would have set up the upstream, and the next\n\"push\" would have followed it.\n\n(or you could \"git push remote local-branch:remote-branch\")\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"187027","messageId":"vpq8vj2mgr3.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"CAHkcothjDBP+cyGRf--mNgwF5Sp2UiR3Gq1Vb-XwsKmMH_JCvA@mail.gmail.com","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-15T08:05:04Z","receivedAt":"2012-03-15T08:05:04Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Dmitry Potapov writes:\n\n> On Wed, Mar 14, 2012 at 6:47 PM, Matthieu Moy\n> wrote:\n>> Dmitry Potapov writes:\n>>\n>>> Not of course. I said above non-fast forward push should not be used by\n>>> beginners.\n>>\n>> Do you mean \"beginners should not force non-fast forward push\", or\n>> \"beginners should not use flow where push may be denied because of\n>> non-fast forward\"?\n>\n> Of course, the former. I have never said that the centralized workflow\n> should never been used. I have only said that it is not scalable and\n> lead to problems in larger projects.\n\nThen I don't follow you. The starting point of the discussion was my\nrule of thumb about push/pull:\n\n| There's a rule of thumb which works very well for beginners: when \"git\n| push\" tells you to pull before, then pull before. This rule of thumb\n| works, but only provided \"push\" and \"pull\" are symmetrical.\n\nI can rephrase the end as \"... provided 'push' pushes to the same branch\n'pull' pulls from\" (i.e. provided push.default=upstream).\n\nCan you explain what you disagree with here? Or do you actually agree\nwith it?\n\nThen, I showed the message of \"git push\" in the non-fast forward case,\nwhich suggests that the user should pull, and you said:\n\n| I agree that the current diagnostic is not suitable for beginners.\n\nAgain, what do you mean? What diagnosis would you suggest, if not\npulling?\n\n>> either shared for one user and multiple machines, or shared\n>> between developers?\n>\n> I am not sure that I understood this part.\n\nI mean that a repository can be shared because multiple developers have\nacces to it, or because the same developer has several clones.\n\n>> If you mean that shared repositories are too complex for beginners, my\n>> experience is exactly the opposite.\n>\n> It is not too complex but it is wrong for any more or less serious\n> project.\n\nI never argued against distributed development. I'm saying that\ncentralized development also makes sense, especially with beginners.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"187040","messageId":"4F61C7C9.8020705@ira.uka.de","threadId":"29881","inReplyTo":"vpqehsumgvd.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-03-15T10:43:21Z","receivedAt":"2012-03-15T10:43:21Z","isPatch":true,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 15.03.2012 09:02, Matthieu Moy wrote:\n> Holger Hellmuth writes:\n>\n>> So today I tried to create a\n>> bidirectional link between a local and a remote branch using only\n>> porcelain commands (i.e. without using git config directly). Somehow I\n>> didn't succeed. I can either use git checkout --track or git push -u\n>> to make a pull connection between the two, but to automatically push I\n>> would have to create a branch of the same name (and know that this is\n>> the magical ingredient that makes it work!)\n>\n> In this particular case, having 'push.default=upstream' would have done\n> it for you: your \"push -u\" would have set up the upstream, and the next\n> \"push\" would have followed it.\n\nI know, this is why I voted for \"upstream\", but there are good reasons \nfor \"current\" too. Whatever is decided on will still get some users by \nsurprise.\n\n> (or you could \"git push remote local-branch:remote-branch\")\n>\n\nSure, I can believe that a new user will be able to get at that line \nafter studying the \"git push\" manual page (or reading a tutorial), but I \nreally doubt he will easily find out where to go from there to simplify \nthat line. And typing that line every time for a permanent connection is \nout of the question, right?\n\nThat is why I think git push --track remote local-branch:remote-branch \n(or --permanent, --perm, --follow, --configure, --keep) would be a great \nhelp because a tutorial wouldn't have to talk about a lot of special \ncases, config options, it could just explain:\n\n-----------------------------\n1) To follow a remote repository do \"git remote add \n2) To follow a remote branch do \"git checkout [-b localbranch] --track \n/. Then \"git pull\" while in this branch will synchronize \nyou whenever you want to be up-to-date.\n3) To get a remote branch to follow you do \"git push --track \n: once. Then \"git push\" while in this branch will \nsynchronize the remote branch.\n-----------------------------\n\nWith this simple recipe 90% of all workflows could be configured by a \nnovice without embarrasing himself. Can you find a similar simple and \nconsise recipe that would work today (even with upstream or current) ? I \ndoubt it.\n\nSorry about opening up another tangent, but this is somewhat connected. \nIf we give the novice an easy instrument to configure what he really \nwants then the default becomes much less important.\n"},{"id":"187076","messageId":"20120316085152.GA22273@ecki","threadId":"29881","inReplyTo":"1331281886-11667-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-03-16T08:51:52Z","receivedAt":"2012-03-16T08:51:52Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"Hi,\n\nOn Fri, Mar 09, 2012 at 09:31:26AM +0100, Matthieu Moy wrote:\n>\n> In preparation for flipping the default to the \"upstream\" mode from the\n> \"matching\" mode that is the upstream default, start warning users when they\n> rely on unconfigured \"git push\" to default to the \"matching\" mode.\n\nI haven't had time to follow the entire discussion, but I have been\nthinking about this myself a little and I also find it hard to decide\nbetween \"current\" and \"upstream\". So I just wanted to throw in another\noption:\n\nIf neither default is the right thing to do, then we should not choose\neither. Instead, by default make push act according to \"current\" or\n\"upstream\" only if they would do the same thing anyways. In other words,\npush the current branch only if it is also tracking a remote branch of\nthe same name.\n\nIf \"current\" and \"upstream\" disagree, git push errors out and asks the\nuser to use an explicit refspec or change push.default according to\ntheir preferred workflow.\n\nClemens\n"},{"id":"187078","messageId":"jjv1me$ts7$1@dough.gmane.org","threadId":"29881","inReplyTo":"87aa3qi2i7.fsf@thomas.inf.ethz.ch","subject":"Re: git push default behaviour?","fromName":"Gelonida N","fromEmail":"gelonida@gmail.com","sentAt":"2012-03-16T09:38:22Z","receivedAt":"2012-03-16T09:38:22Z","isPatch":false,"sender":{"key":"gelonida@gmail.com","avatar":null},"body":"On 03/09/2012 09:48 AM, Thomas Rast wrote:\n> demerphq writes:\n> \n>> A possible solution might be to give config files a \"format version\"\n>> of their own. They already contain a repository format version number,\n>> so add a new variable \"ConfigVersionLevel\". Alongside that you might\n>> introduce a policy of having new git \"fill in\" the defaults missing\n>> from the config file whenever it operates, so that people can\n>> explicitly view then all at once. Then if the defaults change in the\n>> future an old repo will continue to work as it did before. This alone\n>> would allow you to change the defaults for existing configurable\n>> behavior, but you need the version number to handle new options.\n>>\n>> Once you have that you can change the default behavior based on the\n>> version level so that older users operating in older repositories get\n>> the old behavior, and new repositories get the new behavior. And you\n>> have more flexibility in how your approach these problems when they\n>> come up, and it seems to me that they are inevitable.\n> \n> This would be a brilliant way to confuse the hell out of existing users:\n> suddenly the apparent \"defaults\"[1] now change *between repositories*\n> depending on when they were created.\n> \n> In short, oh please god no.\n\nIf config file version changes would occur rarely, then this idea\ndsoesn't sound that bad to me.\ngit could even ask whether it should upgrade (explicitely insert the old\ndefault value if not existing and if different in the new release) the\nconfig file version whenver it encounters an old version.\n\nBy this means old projects wouldn't be broken whenever a default value\nwould be changed and all rconfig files would upgrade to the same version.\n\nEven older versions of git would still work with these upgraded config files\n"},{"id":"187079","messageId":"vpq1uosswwz.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"20120316085152.GA22273@ecki","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-16T09:43:56Z","receivedAt":"2012-03-16T09:43:56Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Clemens Buchacher writes:\n\n> If \"current\" and \"upstream\" disagree, git push errors out and asks the\n> user to use an explicit refspec or change push.default according to\n> their preferred workflow.\n\nI actually like this idea. Or at least, much more than \"current, but\nonly if the remote already exists\". In most simple case, it will just\nwork, and it will error out with an explicit message in every case which\ncould have confused the user.\n\nI'd count \"upstream is not set\" as \"current and upstream agree on\n'current'\". IOW, use \"current\", but error out if there's a configured\nupstream that is different.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"187087","messageId":"7vy5r0iwdb.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"vpq1uosswwz.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-16T12:05:52Z","receivedAt":"2012-03-16T12:05:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> I'd count \"upstream is not set\" as \"current and upstream agree on\n> 'current'\". IOW, use \"current\", but error out if there's a configured\n> upstream that is different.\n\nAnd if there is no configured upstream, should it error out, or should it\njust push the current one to its own name?\n"},{"id":"187089","messageId":"vpqhaxohg3n.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"7vy5r0iwdb.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-16T12:42:36Z","receivedAt":"2012-03-16T12:42:36Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> I'd count \"upstream is not set\" as \"current and upstream agree on\n>> 'current'\". IOW, use \"current\", but error out if there's a configured\n>> upstream that is different.\n>\n> And if there is no configured upstream, should it error out, or should it\n> just push the current one to its own name?\n\nI meant just push the current one to its own name.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"187108","messageId":"7v7gykgwyw.fsf@alter.siamese.dyndns.org","threadId":"29881","inReplyTo":"7vlin4llwx.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-16T19:35:51Z","receivedAt":"2012-03-16T19:35:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>>> Sounds OK from a cursory read, except for a few minor details.\n>>>\n>>> Thanks. Nitpicks follow.\n>>\n>> I'm taking them all. Here's the result:\n>\n> I'd hold onto this version for a few days before I paste it in my\n> blog or send it to k-list in order to give others a chance to\n> improve the text further, but this looks good (obviously) to me.\n>\n> Thanks for getting the ball rolling.\n\nSo a few days passed, and I do not think we heard anything from anybody.\nI am not sure if that means everybody is happy with the wording of the\ndraft, or simply nobody cares, but unless I hear from anybody further on\nthis topic, I'll start my part of distributing this to where I feel are\nappropriate tonight [*1*].\n\nPeople who want to see the default changed, please help the message to\nreach corners where mine wouldn't reach. For that matter, people who \nwant to see that the default remains the same, please do the same.\n\nThanks.\n\n[Footnote]\n\n*1* The places I have in mind are:\n - This list (which may be pointless)\n - linux-kernel@vger.kernel.org\n - http://git-blame.blogspot.com/\n - http://gplus.to/gitster\n - http://gplus.to/git\n - Google internal (there are a few users at $DAYJOB)\n"},{"id":"187111","messageId":"20120316214832.GB25092@ecki","threadId":"29881","inReplyTo":"vpqhaxohg3n.fsf@bauges.imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-03-16T21:48:32Z","receivedAt":"2012-03-16T21:48:32Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Fri, Mar 16, 2012 at 01:42:36PM +0100, Matthieu Moy wrote:\n> Junio C Hamano writes:\n> \n> > Matthieu Moy writes:\n> >\n> >> I'd count \"upstream is not set\" as \"current and upstream agree on\n> >> 'current'\". IOW, use \"current\", but error out if there's a configured\n> >> upstream that is different.\n> >\n> > And if there is no configured upstream, should it error out, or should it\n> > just push the current one to its own name?\n> \n> I meant just push the current one to its own name.\n\nAltough in a somewhat rarer case, this has the same problem as\n\"current\":\n\ngit checkout -b master origin/master\ngit checkout -b topic master\ngit push\n\nIf a branch called topic already exists on origin, push will now try to\nupdate it with the local branch topic. But they do not have any clear\nconnection, except for the name.\n\nClemens\n"},{"id":"187138","messageId":"CAAGHeXHWfEAym63jXFNvcBddp00joBzNuFEjhKZpqDQcn1d0kA@mail.gmail.com","threadId":"29881","inReplyTo":"CAFsnPqp1+jX3ZY0LZ1QDmvA=2_ebApPBttwFjr36OuTX2_MHug@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Sebastien Douche","fromEmail":"sdouche@gmail.com","sentAt":"2012-03-17T09:36:53Z","receivedAt":"2012-03-17T09:36:53Z","isPatch":false,"sender":{"key":"sdouche@gmail.com","avatar":"https://gravatar.com/avatar/1b4a6cb11f6237ff9dc78b953ce48e416afa42e947143e14273cdc2c7f6f9c1a?d=mp&s=160"},"body":"On Thu, Mar 8, 2012 at 11:01, Jeremy Morton wrote:\n> Hi everyone,\n\nHi Jeremy (sorry to be late, back from holiday)\n\n> I've noticed that the default behaviour of 'git push' is to push to\n> *all* branches that have a remote branch set up.  In order to push\n> just to one branch, you must specify 'git push repo branchname'.\n>\n> This seems rather unintuative to me\n\nI made many Git presentation and managed a lot of training[1] and the\nfirst thing I explain on the configuration is :\n\n1. set your name and email\n2. change the default push option[2]\n\nMoreover, most people I see don't understand the default behaviour:\nit's a frequently ask question by beginner.\n\n\n[1] For git French : http://gitfr.net/blog\n[2] I recommend tracking\n\n\n-- \nSebastien Douche \nTwitter: @sdouche / G+: +sdouche\n"},{"id":"187139","messageId":"CAFsnPqpS7srjHu1Wnx60qcwN_PV83uxvtWoniFBgRH2MjJzzzA@mail.gmail.com","threadId":"29881","inReplyTo":"CAAGHeXHWfEAym63jXFNvcBddp00joBzNuFEjhKZpqDQcn1d0kA@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Jeremy Morton","fromEmail":"jeremy@configit.com","sentAt":"2012-03-17T09:38:42Z","receivedAt":"2012-03-17T09:38:42Z","isPatch":false,"sender":{"key":"jeremy@configit.com","avatar":null},"body":"On Sat, Mar 17, 2012 at 9:36 AM, Sebastien Douche wrote:\n> On Thu, Mar 8, 2012 at 11:01, Jeremy Morton wrote:\n>> Hi everyone,\n>\n> Hi Jeremy (sorry to be late, back from holiday)\n>\n>> I've noticed that the default behaviour of 'git push' is to push to\n>> *all* branches that have a remote branch set up.  In order to push\n>> just to one branch, you must specify 'git push repo branchname'.\n>>\n>> This seems rather unintuative to me\n>\n> I made many Git presentation and managed a lot of training[1] and the\n> first thing I explain on the configuration is :\n>\n> 1. set your name and email\n> 2. change the default push option[2]\n\nSo, that would seem to be a rather strong indication that the default\npush option is a bad one. :-)\n\nBest regards,\nJeremy Morton (Jez)\n"},{"id":"187140","messageId":"CAAGHeXFFrHnDz-SA8V2awBpi3Cwfxj_C3p=N16qZZFEW3L5Vtw@mail.gmail.com","threadId":"29881","inReplyTo":"CAFsnPqpS7srjHu1Wnx60qcwN_PV83uxvtWoniFBgRH2MjJzzzA@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Sebastien Douche","fromEmail":"sdouche@gmail.com","sentAt":"2012-03-17T09:51:26Z","receivedAt":"2012-03-17T09:51:26Z","isPatch":false,"sender":{"key":"sdouche@gmail.com","avatar":"https://gravatar.com/avatar/1b4a6cb11f6237ff9dc78b953ce48e416afa42e947143e14273cdc2c7f6f9c1a?d=mp&s=160"},"body":"On Sat, Mar 17, 2012 at 10:38, Jeremy Morton wrote:\n>> I made many Git presentation and managed a lot of training[1] and the\n>> first thing I explain on the configuration is :\n>>\n>> 1. set your name and email\n>> 2. change the default push option[2]\n>\n> So, that would seem to be a rather strong indication that the default\n> push option is a bad one.  :-)\n\nTrue. Never understood why matching is the default value :). Btw,\nthank you for the discussion, I forgot to do that :(.\n\n-- \nSebastien Douche \nTwitter: @sdouche / G+: +sdouche\n"},{"id":"187159","messageId":"loom.20120317T164347-871@post.gmane.org","threadId":"29881","inReplyTo":"7vwr6u6qrn.fsf@alter.siamese.dyndns.org","subject":"Re: git push default behaviour?","fromName":"Eric Hanchrow","fromEmail":"eric.hanchrow@gmail.com","sentAt":"2012-03-17T15:49:37Z","receivedAt":"2012-03-17T15:49:37Z","isPatch":false,"sender":{"key":"eric.hanchrow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3145?v=4"},"body":"In response to\nhttp://git-blame.blogspot.com/2012/03/please-discuss-what-git-push-should-do.html:\n\nI think either 'current' or 'upstream' is a better default than\n'matching', since it's less likely to surprise newbies. However, I\ncannot decide which of 'current' or 'upstream' is the best choice. It\nmight be worthwhile to have 'git push' warn when someone has\npush.default = current or push.default = upstream, AND when @{u} has a\ndifferent name than the local branch -- in other words, emit a warning\nwhen 'upstream'' and 'current' refer to different branches. The\nwarning itself should be turn-off-able, since it would get pretty old\npretty quickly.\n"},{"id":"187177","messageId":"vpqvcm3vttw.fsf@bauges.imag.fr","threadId":"29881","inReplyTo":"20120316214832.GB25092@ecki","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-17T20:46:51Z","receivedAt":"2012-03-17T20:46:51Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Clemens Buchacher writes:\n\n> On Fri, Mar 16, 2012 at 01:42:36PM +0100, Matthieu Moy wrote:\n>> Junio C Hamano writes:\n>> \n>> > Matthieu Moy writes:\n>> >\n>> >> I'd count \"upstream is not set\" as \"current and upstream agree on\n>> >> 'current'\". IOW, use \"current\", but error out if there's a configured\n>> >> upstream that is different.\n>> >\n>> > And if there is no configured upstream, should it error out, or should it\n>> > just push the current one to its own name?\n>> \n>> I meant just push the current one to its own name.\n>\n> Altough in a somewhat rarer case, this has the same problem as\n> \"current\":\n>\n> git checkout -b master origin/master\n> git checkout -b topic master\n> git push\n>\n> If a branch called topic already exists on origin, push will now try to\n> update it with the local branch topic. But they do not have any clear\n> connection, except for the name.\n\nYes, but the user can hardly expect anything else here. So, it may be a\n(user) mistake, but it's not a surprise.\n\nBTW, 'matching' also has this drawback, and I never saw anyone complain\nabout it (maybe I didn't listen enough though).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"187203","messageId":"CADDfn-Jwh1Uyw1J4qmOv6PFzHF8JM5Lgg_dKcCoa+LvT-fk70Q@mail.gmail.com","threadId":"29881","inReplyTo":"CAAGHeXFFrHnDz-SA8V2awBpi3Cwfxj_C3p=N16qZZFEW3L5Vtw@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Pavel Pospíšil","fromEmail":"pospispa@gmail.com","sentAt":"2012-03-18T10:26:09Z","receivedAt":"2012-03-18T10:26:09Z","isPatch":false,"sender":{"key":"pospispa@gmail.com","avatar":null},"body":"Hi,\nI consider myself a little bit experienced git newbie. I use git 1.7.5.4\nI use git for 9 month in this way:\n1. copy a released version from a centralized versioning control\nsystem (this VCS does not have any git interface) to my local git repo\n2. do work in git in my-branch\n3. copy current work-in-progress reconfiguration from VCS to git\n4. rebase my-branch onto current work-in-progress\n5. copy my work to VCS\nTherefore, no usage of push/pull.\n\nI created my first public repo in which I share the released versions\nof 4 development streams in 4 independent branches with my colleagues.\nMy usual workflow is:\n1. copy a released version from VCS to my local git repo\n2. git add .\n3. git commit\n4. git tag \n5. git push HEAD\n6. git push \nI expected that push is meant (even after reading man git-push) to be\nused in this way:\n1. do some work in my-branch\n2. merge it to master\n3. git push\nand this will push only the changes in the master branch I am\ncurrently switched on.\n\nNow, I realized that git push default is not \"upstream\" (the behaviour\nI expected) but is \"matching\" that brings more automation (I assume\ngit community wants to achieve as much automation as possible).\n\nI agree with Sebastien that current git push.default is too much\nautomation for newbies that \"upstream\" would be a better default for\nnewbies.\n\nI came across an inconvenience in man git-push. There is no\nConfiguration section that will inform about the push.default\nconfiguration parameter and educate the reading about various push\nbehaviours. I know that there is man git-config but it's too long and\nit's too tedious to read all git configuration options.\n\nMaybe, adding the Configuration section to man git-push will help.\n\nBest regards,\nPavel Pospisil\n\n\nOn Sat, Mar 17, 2012 at 10:51 AM, Sebastien Douche wrote:\n>\n> On Sat, Mar 17, 2012 at 10:38, Jeremy Morton wrote:\n> >> I made many Git presentation and managed a lot of training[1] and the\n> >> first thing I explain on the configuration is :\n> >>\n> >> 1. set your name and email\n> >> 2. change the default push option[2]\n> >\n> > So, that would seem to be a rather strong indication that the default\n> > push option is a bad one.  :-)\n>\n> True. Never understood why matching is the default value :). Btw,\n> thank you for the discussion, I forgot to do that :(.\n>\n> --\n> Sebastien Douche \n> Twitter: @sdouche / G+: +sdouche\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"187239","messageId":"buoy5qxi0vx.fsf@dhlpc061.dev.necel.com","threadId":"29881","inReplyTo":"CAFsnPqpoBLHoshgv0MsUUStA3Q=niM8hP9yaHr+rSQvh-JWHZA@mail.gmail.com","subject":"Re: git push default behaviour?","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2012-03-19T06:02:42Z","receivedAt":"2012-03-19T06:02:42Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jeremy Morton writes:\n> Obviously - but my point is that it needn't be so dangerous by\n> default. It tries to push all matching branches - is that really a\n> more common requirement than pushing the current branch?\n\nIt isn't \"so dangerous\" by default -- you have to specify --force to\nenter \"danger\" territory, and --force is very clearly a dangerous\noption that needs to be approached carefully (someone who uses --force\nblindly is going to quickly screw themselves regardless of the\ndefaults).\n\n-miles\n\n-- \nZeal, n. A certain nervous disorder afflicting the young and inexperienced.\n"},{"id":"187255","messageId":"loom.20120319T170700-42@post.gmane.org","threadId":"29881","inReplyTo":"1331281886-11667-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [RFC PATCH] push: start warning upcoming default change for push.default","fromName":"Andrew Myers","fromEmail":"asm198@gmail.com","sentAt":"2012-03-19T16:11:10Z","receivedAt":"2012-03-19T16:11:10Z","isPatch":true,"sender":{"key":"asm198@gmail.com","avatar":null},"body":"I would like to register my vote to change the default behavior of git push\nto either current (preferred) or upstream. I'm the git admin on my team which\nuses a shared repository with many branches. The current default behavior\nhas caused confusion and problems for inexperienced users (or users who refuse\nto self educate). While the optimum solution would be users who learn the\nsystem but this change would make (at least) my job easier.\n"},{"id":"187254","messageId":"CAGK7Mr7Wf4S-OaWiQY3vWxKzhSV6nu76kVsWMbC_8GFghrfaJw@mail.gmail.com","threadId":"29881","inReplyTo":"buoy5qxi0vx.fsf@dhlpc061.dev.necel.com","subject":"Re: git push default behaviour?","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2012-03-19T16:12:21Z","receivedAt":"2012-03-19T16:12:21Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"FWIW I also think we'd change the default to \"upstream\". The problem\nwith this default is that most repos only have one branch (master) and\nthus they never run into this problem, so most people don't get the\nhabit to modify push.default AND they get the (bad) habit of typing\n\"git push\". Then they work with multiple branches and get unexpected\npushes (with or without --force, especially when sausage making).\n\nI know it's \"their\" fault for not learning more about git push's\ndefaults, but the current default is clearly against the principle of\nleast surprise IMHO.\n\nPhilippe\n"}]}