{"thread":{"id":"19308","subject":"git push origin error (1.6.3 new default functionality)","startedAt":"2009-05-12T01:26:19Z","lastAt":"2009-05-14T08:57:32Z","messageCount":14,"participants":["Caleb Cushing","Michael J Gruber","Jeff King","Johannes Sixt","Junio C Hamano","Finn Arne Gangstad"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"113607","messageId":"81bfc67a0905111826y779555cer6679da11db787ab1@mail.gmail.com","threadId":"19308","inReplyTo":null,"subject":"git push origin error (1.6.3 new default functionality)","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2009-05-12T01:26:19Z","receivedAt":"2009-05-12T01:26:19Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"in the past git push origin would just push all matching branches to\nthe remote, and it worked. the new error says that's still the\ndefault. The new functionality is nice, but is it really the git way\nto yell at you if you haven't explicitly set the default? I think the\ndefault should remain the default, and it should continue to work\nwithout yelling at you for not explicitly setting it. if you want to\nchange it that's fine.\n\n-- \nCaleb Cushing\n\nhttp://xenoterracide.blogspot.com\n"},{"id":"113628","messageId":"4A09594F.4040603@drmicha.warpmail.net","threadId":"19308","inReplyTo":"81bfc67a0905111826y779555cer6679da11db787ab1@mail.gmail.com","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-05-12T11:11:11Z","receivedAt":"2009-05-12T11:11:11Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Caleb Cushing venit, vidit, dixit 12.05.2009 03:26:\n> in the past git push origin would just push all matching branches to\n> the remote, and it worked. the new error says that's still the\n> default. The new functionality is nice, but is it really the git way\n> to yell at you if you haven't explicitly set the default? I think the\n> default should remain the default, and it should continue to work\n> without yelling at you for not explicitly setting it. if you want to\n> change it that's fine.\n> \n\\begin{rambling}\nIt is a fall-out from the new user friendliness initiative. Watch out\nfor parentheses:\nit's ( (new user) friendliness ), not ( new (user friendliness) ).\n\nThe principle is: if a user is about to do something which is documented\nbut might not have been intended we throw a half-screen full of text at\nthem. The idea is that it is virtually impossible to grasp at a glance\nfrom that much text what happened, so that the user is forced to read\nthe whole text. edugit, so to say.\n\\end{rambling}\n\nSeriously, we had that discussion when the feature (change of default\nbehaviour) and warning were introduced, so it's too late for a change.\nBut it's never too late to do\n\ngit config --global push.default matching\n\nand be done with it.\n\nThe weird thing is that the default is \"matching\" already. But it makes\na difference whether you have set the variable to its default value\nexplicitly or not. No man page says so (neither git-push nor\ngit-config), and I can't think of other variables with such a behaviour.\n\nMichael\n"},{"id":"113719","messageId":"81bfc67a0905122226p113e4aa5y2a3523ac63de77fc@mail.gmail.com","threadId":"19308","inReplyTo":"4A09594F.4040603@drmicha.warpmail.net","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2009-05-13T05:26:26Z","receivedAt":"2009-05-13T05:26:26Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"On Tue, May 12, 2009 at 7:11 AM, Michael J Gruber\n wrote:\n> Seriously, we had that discussion when the feature (change of default\n> behaviour) and warning were introduced, so it's too late for a change.\n> But it's never too late to do\n>\n\nIt's open source. it's too late to change 1.6.3 but the error message\ncould be easily remove in 1.6.3.1\n\nI'll reiterate that I shouldn't have to explicitly set default\nbehavior to not see error messages.\n-- \nCaleb Cushing\n\nhttp://xenoterracide.blogspot.com\n"},{"id":"113743","messageId":"20090513083203.GA25058@sigill.intra.peff.net","threadId":"19308","inReplyTo":"81bfc67a0905122226p113e4aa5y2a3523ac63de77fc@mail.gmail.com","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-05-13T08:32:03Z","receivedAt":"2009-05-13T08:32:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 13, 2009 at 01:26:26AM -0400, Caleb Cushing wrote:\n\n> On Tue, May 12, 2009 at 7:11 AM, Michael J Gruber\n> wrote:\n> > Seriously, we had that discussion when the feature (change of default\n> > behaviour) and warning were introduced, so it's too late for a change.\n> > But it's never too late to do\n> >\n> \n> It's open source. it's too late to change 1.6.3 but the error message\n> could be easily remove in 1.6.3.1\n> \n> I'll reiterate that I shouldn't have to explicitly set default\n> behavior to not see error messages.\n\nAre you proposing not to change the default behavior? If you are, then\nyou should at least address the concerns raised in all of the existing\nthreads.\n\nOr are you proposing to still change the default behavior, but drop the\nwarning whose aim is to inform people about the impending change? In\nthat case, I think you should address the concerns that arose from\nprevious changes in default behavior (and which this warning is meant to\naddress), and propose an alternate plan for making the transition more\nsmooth.\n\n-Peff\n"},{"id":"113745","messageId":"4A0A8871.6080107@viscovery.net","threadId":"19308","inReplyTo":"20090513083203.GA25058@sigill.intra.peff.net","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-05-13T08:44:33Z","receivedAt":"2009-05-13T08:44:33Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Context: This is about the warning that a plain \"git push\" produces if no\npush refspec are configured. The default behavior is to push matching\nbranches.\n\nJeff King schrieb:\n> Or are you proposing to still change the default behavior, but drop the\n> warning whose aim is to inform people about the impending change? In\n> that case, I think you should address the concerns that arose from\n> previous changes in default behavior (and which this warning is meant to\n> address), and propose an alternate plan for making the transition more\n> smooth.\n\nUnfortunately, the case with this warning is not that \"simple\" because it\nis not about a planned change of the default behavior, but about a default\nbehavior that may be unexpected for newbies (see the release notes of\n1.6.3). I *can* understand that Caleb is upset by the warning, since he's\ncomfortable with the (current and future) default behavior. But I don't\nknow what to do in cases like these.\n\n-- Hannes\n"},{"id":"113747","messageId":"20090513090317.GA3421@sigill.intra.peff.net","threadId":"19308","inReplyTo":"4A0A8871.6080107@viscovery.net","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-05-13T09:03:17Z","receivedAt":"2009-05-13T09:03:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 13, 2009 at 10:44:33AM +0200, Johannes Sixt wrote:\n\n> Unfortunately, the case with this warning is not that \"simple\" because it\n> is not about a planned change of the default behavior, but about a default\n> behavior that may be unexpected for newbies (see the release notes of\n> 1.6.3). I *can* understand that Caleb is upset by the warning, since he's\n> comfortable with the (current and future) default behavior. But I don't\n> know what to do in cases like these.\n\nI thought this was in preparation for an eventual change, but I might be\nwrong (1.6.3 introduced several such warnings).\n\nRegardless, my point was: the warning was introduced for a purpose\n(either to point out potentially confusing behavior, or to warn the user\nabout an upcoming change in default behavior). Showing up now and saying\n\"I don't like this warning\" without addressing any of the points in the\noriginal discussion or making any sort of proposal to try to accomplish\nthe same goals is just counterproductive.\n\n-Peff\n"},{"id":"113756","messageId":"4A0A98CC.2090701@drmicha.warpmail.net","threadId":"19308","inReplyTo":"20090513090317.GA3421@sigill.intra.peff.net","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-05-13T09:54:20Z","receivedAt":"2009-05-13T09:54:20Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 13.05.2009 11:03:\n> On Wed, May 13, 2009 at 10:44:33AM +0200, Johannes Sixt wrote:\n> \n>> Unfortunately, the case with this warning is not that \"simple\" because it\n>> is not about a planned change of the default behavior, but about a default\n>> behavior that may be unexpected for newbies (see the release notes of\n>> 1.6.3). I *can* understand that Caleb is upset by the warning, since he's\n>> comfortable with the (current and future) default behavior. But I don't\n>> know what to do in cases like these.\n> \n> I thought this was in preparation for an eventual change, but I might be\n> wrong (1.6.3 introduced several such warnings).\n> \n> Regardless, my point was: the warning was introduced for a purpose\n> (either to point out potentially confusing behavior, or to warn the user\n> about an upcoming change in default behavior). Showing up now and saying\n> \"I don't like this warning\" without addressing any of the points in the\n> original discussion or making any sort of proposal to try to accomplish\n> the same goals is just counterproductive.\n\nI don't want to stir this up to much again - as I said, set config and\nbe done.\n\nMy main issue is the fact that we have a config variable (push.default)\nwhich causes a different behaviour depending on whether it is unset or\nset to its default (!) value. That is a completely new UI approach. We\nmay follow through with this for a \"beginners' mode\" for git, where\ncommands with possibly unintended side effects issue warnings, as\nopposed to an \"advanced mode\" (activated by 1 config variable) which\nshuts these off. Right now this new behaviour is isolated and feels strange.\n\nMichael\n"},{"id":"113823","messageId":"7vprec4znj.fsf@alter.siamese.dyndns.org","threadId":"19308","inReplyTo":"4A09594F.4040603@drmicha.warpmail.net","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-13T18:37:52Z","receivedAt":"2009-05-13T18:37:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Seriously, we had that discussion when the feature (change of default\n> behaviour) and warning were introduced, so it's too late for a change.\n> But it's never too late to do\n>\n> git config --global push.default matching\n>\n> and be done with it.\n\nThanks for saying this concisely, and saving me from repeating this.\n\n> The weird thing is that the default is \"matching\" already. But it makes\n> a difference whether you have set the variable to its default value\n> explicitly or not. No man page says so (neither git-push nor\n> git-config), and I can't think of other variables with such a behaviour.\n\nIt is not weird at all. Although I am still not convinced (and I suspect\nsome old timers are not either), the default could change in the future\nand by setting it to 'matching', you will protect yourself from such a\nchange. Consider it a vaccination ;-)\n"},{"id":"113866","messageId":"81bfc67a0905132030g39432e63ne72ace88edf79848@mail.gmail.com","threadId":"19308","inReplyTo":"7vprec4znj.fsf@alter.siamese.dyndns.org","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2009-05-14T03:30:41Z","receivedAt":"2009-05-14T03:30:41Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"On Wed, May 13, 2009 at 2:37 PM, Junio C Hamano wrote:\n> Thanks for saying this concisely, and saving me from repeating this.\n\nI just don't think one should have to explicitly set something to shut\nwarnings up. defaults are there for a reason. next thing you know it's\ngoing to ask me if I'd like to continue, and then it will ask me to\npress n for next.\n\nWhy even have them? if people want to know what's changed they should\nread release notes.\n\nmaybe a better solution would be to have a setting. set all warnings to off...\n-- \nCaleb Cushing\n\nhttp://xenoterracide.blogspot.com\n"},{"id":"113871","messageId":"7vab5gz41o.fsf@alter.siamese.dyndns.org","threadId":"19308","inReplyTo":"81bfc67a0905132030g39432e63ne72ace88edf79848@mail.gmail.com","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-14T04:44:51Z","receivedAt":"2009-05-14T04:44:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Caleb Cushing writes:\n\n> On Wed, May 13, 2009 at 2:37 PM, Junio C Hamano wrote:\n>> Thanks for saying this concisely, and saving me from repeating this.\n>\n> I just don't think one should have to explicitly set something to shut\n> warnings up. defaults are there for a reason. next thing you know it's\n> going to ask me if I'd like to continue, and then it will ask me to\n> press n for next.\n>\n> Why even have them?\n\nWhy do you waste other people's time after repeatedly told this was\ndiscussed to death and everything is recoded in the list archive?\n"},{"id":"113880","messageId":"7vtz3oxnej.fsf@alter.siamese.dyndns.org","threadId":"19308","inReplyTo":"7vab5gz41o.fsf@alter.siamese.dyndns.org","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-14T05:29:40Z","receivedAt":"2009-05-14T05:29:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Caleb Cushing writes:\n>\n>> On Wed, May 13, 2009 at 2:37 PM, Junio C Hamano wrote:\n>>> Thanks for saying this concisely, and saving me from repeating this.\n>>\n>> I just don't think one should have to explicitly set something to shut\n>> warnings up. defaults are there for a reason. next thing you know it's\n>> going to ask me if I'd like to continue, and then it will ask me to\n>> press n for next.\n>>\n>> Why even have them?\n>\n> Why do you waste other people's time after repeatedly told this was\n> discussed to death and everything is recoded in the list archive?\n\nYou know what is most frustrating for me with this whole thing?\n\nAs you might have guessed already, I am one of the oldest users of git, am\naccustomed to the way \"matching push\" works, and I like it as a sensible\ndefault behaviour for _my workflow_. If I, Linus and you were the only\ngit users, there won't be these half-page-full of warning messages.\n\nBut there are others, and one of them was motivated enough to write a\npatch series to introduce push.default that allows a setting that may be\nmore suitable than 'matching' in certain workflows, even though I may not\never use that workflow in my projects myself. This early vaccination\napproach was the least evil solution proposed back then (which I think was\nmodelled after the already in-progress \"deny git push from updating the\ncurrent branch\" topic), and you were not around to know that I even toned\ndown the series not to make it too strongly suggest that the default will\nchange.\n\nNo, \"you were not around\" part is not what is frustrating. What is\nfrustrating is that the original author who felt strongly enough against\n'matching' default to write the patch is not defending the change in this\nthread, and I have to spend time writing responses like this that I\notherwise could be using for something else to improve the project with.\nAnd what is even more frustrating is that I cannot afford the time to\nrepeat the full discussion here (nor I have inclinations to), and if you\nare the type who does not do his own homework, it would appear to you as\nif I am all for changing the default and as if I am being unreasonable.\n\nI do not mind appearing to be a bad guy to you or anybody per-se, but I\nthink people who got what they wanted earlier should come and defend the\nreason why they got what they wanted.\n\nI am nice enough not to threaten them by saying something like \"since\nnobody seems to be serious enough to defend this earlier change, let's\nchange our mind and get rid of that warning\" ;-)\n\nOh, I already anticipate that I'll have the same frustration defending the\n\"deny git push from updating the current branch\" that was settled eons\nago. I am not looking forward to it.\n"},{"id":"113886","messageId":"20090514063157.GA10411@coredump.intra.peff.net","threadId":"19308","inReplyTo":"4A0A98CC.2090701@drmicha.warpmail.net","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-05-14T06:31:57Z","receivedAt":"2009-05-14T06:31:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 13, 2009 at 11:54:20AM +0200, Michael J Gruber wrote:\n\n> > Regardless, my point was: the warning was introduced for a purpose\n> > (either to point out potentially confusing behavior, or to warn the user\n> > about an upcoming change in default behavior). Showing up now and saying\n> > \"I don't like this warning\" without addressing any of the points in the\n> > original discussion or making any sort of proposal to try to accomplish\n> > the same goals is just counterproductive.\n> \n> I don't want to stir this up to much again - as I said, set config and\n> be done.\n\nJunio already posted a thoughtful (if perhaps somewhat frustrated) reply\nelsewhere, and I agree with most of what he said. I did want to make one\nadditional point, though, because I think what I said may have appeared\nmean. And I was really trying to be nice.\n\nMy initial reaction was to say \"shut up and set the config variable\".\nBut I really don't like doing that, because I don't want somebody\nthinking that all decisions are closed, and it's not possible to come to\nthe table with new points that may make people change their minds.\n\nWhen the subject was discussed before, there were people who preferred\nvarious behaviors. They each made arguments, and in the aftermath, Junio\nmade a decision (presumably based on arguments by list members, opinions\nof other developers, and whatever he thought was best) about what to\napply.\n\nIf somebody wants to bring up a new argument, new data, or point out\nsome or changed circumstance that may affect the decision, then I am all\nfor them doing so. And that is what I was trying to coax out of Caleb.\nBut without that, I don't see any reason why others should waste their\ntime reconsidering the decision. Let's assume that the original decision\nmaking process was at least roughly deterministic and would just arrive\nat the same answer.\n\nAnd I think simply posting a \"I would have been on the side to prefer X\"\nopinion isn't really new data. It pushes the tally for that preference\nup by one, but the margin of error on such tallies is already huge (I\nthink we have seen in the past that there is a silent majority who are\n_not_ on the git list, and we need to try to address their interests as\nwell). So while something like a well-managed survey of what git users\nwould prefer is new data, I consider a single (or even several) \"me too\"\nmessages on the list to just be noise in the data.\n\n> My main issue is the fact that we have a config variable (push.default)\n> which causes a different behaviour depending on whether it is unset or\n> set to its default (!) value. That is a completely new UI approach. We\n\nWell, it depends on how you think of the default. The default could be\n\"matched-and-warn\", and you are fixing it by setting it to \"matched\". :)\n\n-Peff\n"},{"id":"113901","messageId":"4A0BCA43.9080408@drmicha.warpmail.net","threadId":"19308","inReplyTo":"20090514063157.GA10411@coredump.intra.peff.net","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-05-14T07:37:39Z","receivedAt":"2009-05-14T07:37:39Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 14.05.2009 08:31:\n> On Wed, May 13, 2009 at 11:54:20AM +0200, Michael J Gruber wrote:\n\n[snip snip snip]\n\n>> My main issue is the fact that we have a config variable (push.default)\n>> which causes a different behaviour depending on whether it is unset or\n>> set to its default (!) value. That is a completely new UI approach. We\n> \n> Well, it depends on how you think of the default. The default could be\n> \"matched-and-warn\", and you are fixing it by setting it to \"matched\". :)\n> \n> -Peff\n\nSo, then we have a config variable which you can set to its default\nvalue only by /unsetting/ it :)\n\nIn fact, I think that approach could be valuable in general, making git\nmore fool-proof for beginners while remaining efficient for the\nregulars. As a new concept, to be taken up by \"deny non-ff pushes\",\n\"deny delation pushes\", \"pull without refspec\" etc., I would like that.\nIn order to be useful, beginners should be able to rely on it, i.e.:\nunless certain config is set, the git-gun should never go off when\npointed at users' own feet. Might be a worthy target for 1.7 (pun\nsemi-intended).\n\nMichael\n"},{"id":"113911","messageId":"20090514085732.GA13642@pvv.org","threadId":"19308","inReplyTo":"7vtz3oxnej.fsf@alter.siamese.dyndns.org","subject":"Re: git push origin error (1.6.3 new default functionality)","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-05-14T08:57:32Z","receivedAt":"2009-05-14T08:57:32Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Wed, May 13, 2009 at 10:29:40PM -0700, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Caleb Cushing writes:\n> >\n> >> On Wed, May 13, 2009 at 2:37 PM, Junio C Hamano wrote:\n> >>> Thanks for saying this concisely, and saving me from repeating this.\n> >>\n> >> I just don't think one should have to explicitly set something to shut\n> >> warnings up. defaults are there for a reason. next thing you know it's\n> >> going to ask me if I'd like to continue, and then it will ask me to\n> >> press n for next.\n> >>\n> >> Why even have them?\n> >\n> > Why do you waste other people's time after repeatedly told this was\n> > discussed to death and everything is recoded in the list archive?\n> \n> You know what is most frustrating for me with this whole thing?\n> \n> As you might have guessed already, I am one of the oldest users of git, am\n> accustomed to the way \"matching push\" works, and I like it as a sensible\n> default behaviour for _my workflow_. If I, Linus and you were the only\n> git users, there won't be these half-page-full of warning messages.\n> \n> But there are others, and one of them was motivated enough to write a\n> patch series to introduce push.default that allows a setting that may be\n> more suitable than 'matching' in certain workflows, even though I may not\n> ever use that workflow in my projects myself. This early vaccination\n> approach was the least evil solution proposed back then (which I think was\n> modelled after the already in-progress \"deny git push from updating the\n> current branch\" topic), and you were not around to know that I even toned\n> down the series not to make it too strongly suggest that the default will\n> change.\n> \n> No, \"you were not around\" part is not what is frustrating. What is\n> frustrating is that the original author who felt strongly enough against\n> 'matching' default to write the patch is not defending the change in this\n> thread, and I have to spend time writing responses like this that I\n> otherwise could be using for something else to improve the project with.\n\nI am sorry to be the primary source of your frustration.\n\nAnyway, to summarize the old thread quickly from my point of view:\n\n\"git push\" is a very dangerous operation if you are using multiple\nremotes, and you are not the owner/maintaner of all of them. A very\ncommon workflow where this is wrong is when using a shared pushable\nrepo.\n\nAdvanced users can configure push as they want, the default is most\nimportant for new users. From the discussions we had it seems that it\nis not possible to make a default that works well for different\nworkflows, so I argue we should make the least dangerous default the\ndefault. I would like to change the default behaviour of \"git push\" to\ndo nothing at all, and to give a short message hinting at how to\nconfigure it if you invoke git push without any arguments.\n\nThe current state of git as of 1.6.3.1, to push matching, but to\ncomplain, is not a good terminal state I think. I have also noticed\nthat printing long warnings (10+ lines) is not helpful for people,\nthey really need to be as short as possible or they will not be read\nor understood. So, something like this as the next stage perhaps (this\nis not complete, man-pages and some tests should be updated as well):\n\n--8<--\ndiff --git a/builtin-push.c b/builtin-push.c\nindex 2eabcd3..80c81ea 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -65,18 +65,8 @@ static void setup_push_tracking(void)\n }\n \n static const char *warn_unconfigured_push_msg[] = {\n-\t\"You did not specify any refspecs to push, and the current remote\",\n-\t\"has not configured any push refspecs. The default action in this\",\n-\t\"case is to push all matching refspecs, that is, all branches\",\n-\t\"that exist both locally and remotely will be updated. This may\",\n-\t\"not necessarily be what you want to happen.\",\n-\t\"\",\n-\t\"You can specify what action you want to take in this case, and\",\n-\t\"avoid seeing this message again, by configuring 'push.default' to:\",\n-\t\" 'nothing' : Do not push anything\",\n-\t\" 'matching' : Push all matching branches (default)\",\n-\t\" 'tracking' : Push the current branch to whatever it is tracking\",\n-\t\" 'current' : Push the current branch\"\n+\t\"Nothing to push, and push.default is not configured.\",\n+\t\"See git-push(1) and git-config(1) for details.\"\n };\n \n static void warn_unconfigured_push(void)\n@@ -92,7 +82,8 @@ static void setup_default_push_refspecs(void)\n \tswitch (push_default) {\n \tcase PUSH_DEFAULT_UNSPECIFIED:\n \t\twarn_unconfigured_push();\n-\t\t/* fallthrough */\n+\t\texit(EXIT_FAILURE);\n+\t\tbreak;\n \n \tcase PUSH_DEFAULT_MATCHING:\n \t\tadd_refspec(\":\");\n--8<--\n\n- Finn Arne\n"}]}