{"thread":{"id":"29973","subject":"Please discuss: what \"git push\" should do when you do not say what to push?","startedAt":"2012-03-17T05:10:39Z","lastAt":"2012-03-21T18:05:02Z","messageCount":43,"participants":["Junio C Hamano","Andrew Sayers","Joey Hess","fREW Schmidt","H. Peter Anvin","Marcus D. Hanwell","Sebastian Schuberth","Ævar Arnfjörð Bjarmason","Sebastien Douche","Peter Krefting","Jonathan Nieder","Kevin Ballard","demerphq","Antony Male","Nathan Gray","Andreas Ericsson","Ben Tebulin","Jakub Narebski","Filipe Fernandes","Martin Langhoff","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"187134","messageId":"7v7gyjersg.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":null,"subject":"Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-17T05:10:39Z","receivedAt":"2012-03-17T05:10:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"There is a proposal to change the default behaviour of 'git push' on the\nGit mailing list. The goal of this message is to encourage you to discuss\nit before it happens (or the change is aborted, depending on the outcome\nof 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 own\npublic repository, but may be confusing if not dangerous when using a\nshared repository. The proposal is to change the default to 'upstream',\ni.e. push only the current branch, and push it to the branch 'git pull'\nwould pull from. Another candidate is 'current'; this pushes only the\ncurrent branch to the remote branch of the same name.\n\nFor more details on the behavior of Git with these values, read the\ndocumentation 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 rely\non the default that pushes all your matching branches. On the other hand,\nyou may want to see the default behaviour to change, especially if you are\nusing shared repositories. In either case, please join the discussion to\ngive us more data point and help us decide the future of Git. Also, if\nyou think your friends and colleagues will be affected by this change,\neither positively or negatively, please tell them about this discussion.\n\nWhat has been discussed so far can be seen in this thread:\n\n http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694\n\nPrevious relevant discussions include:\n\n http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541\n http://thread.gmane.org/gmane.comp.version-control.git/166743\n\nTo join the discussion, send your messages to:\n\n git@vger.kernel.org\n\nThe list accepts messages from non-subscribers, and you do not have to ask\n\"please Cc me, I am not subscribed\", as it's customary to Cc: posters when\nreplying on this list.\n"},{"id":"187135","messageId":"7vty1ndcoi.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"7v7gyjersg.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-17T05:22:21Z","receivedAt":"2012-03-17T05:22:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"If the conclusion of the discussion is that we will change the default,\nthe transition to the new default will go like this:\n\n 1. An announcement message to let the user communities know about the\n future change will be distributed in a way similar to the previous\n request-for-discussion message was distributed.\n\n 2. The first version of Git that is released after such an announcement\n will start issuing a warning when you type \"git push\" to send the\n matching branches to the default location unless you have configured\n push.default variable. The users who want to keep the current default\n can do\n\n\t$ git config push.default matching\n\n and the users who want to use different settings can do one of:\n\n\t$ git config push.default current\n\t$ git config push.default upstream\n\t$ git config push.default nothing\n\n to silence this warning. The warning will be issued unless you do so,\n to help those who missed the message #1.\n\n 3. We wait for a few release cycles.\n\n 4. The default changes. If you do not configure push.default variable,\n it no longer defaults to matching, but does something else (the choice\n among the three other alternatives will be decided in the discussion).\n The warning message will be reworded---instead of saying \"will stop\n being the 'matching' in the future\", it will say \"has changed to X\".\n\n 5. We wait for a few release cycles.\n\n 6. The warning is removed.\n\nA typical release cycle lasts for 8-10 weeks.\n"},{"id":"187141","messageId":"4F6461D7.40303@pileofstuff.org","threadId":"29973","inReplyTo":"7vty1ndcoi.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-03-17T10:05:11Z","receivedAt":"2012-03-17T10:05:11Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 17/03/12 05:22, Junio C Hamano wrote:\n> If the conclusion of the discussion is that we will change the default,\n> the transition to the new default will go like this:\n> \n> 1. An announcement message to let the user communities know about the\n> future change will be distributed in a way similar to the previous\n> request-for-discussion message was distributed.\n> \n> 2. The first version of Git that is released after such an announcement\n> will start issuing a warning when you type \"git push\" to send the\n> matching branches to the default location unless you have configured\n> push.default variable. The users who want to keep the current default\n> can do\n> \n> \t$ git config push.default matching\n> \n> and the users who want to use different settings can do one of:\n> \n> \t$ git config push.default current\n> \t$ git config push.default upstream\n> \t$ git config push.default nothing\n> \n> to silence this warning. The warning will be issued unless you do so,\n> to help those who missed the message #1.\n> \n> 3. We wait for a few release cycles.\n> \n> 4. The default changes. If you do not configure push.default variable,\n> it no longer defaults to matching, but does something else (the choice\n> among the three other alternatives will be decided in the discussion).\n> The warning message will be reworded---instead of saying \"will stop\n> being the 'matching' in the future\", it will say \"has changed to X\".\n> \n> 5. We wait for a few release cycles.\n> \n> 6. The warning is removed.\n> \n> A typical release cycle lasts for 8-10 weeks.\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> \n\nUnfortunately, \"a few release cycles\" strikes me as a rather hopeful\ndescription. For example, a user installing the new Ubuntu LTS release\n(due out next month) would feel completely justified in not upgrading\nuntil 2017, whereas the rest of us would get rather bored disabling the\nsame old warning in every new repo we create for the next five years.\n\nCould I suggest when a user inits/clones a new repository using a\npost-change version of git, we do an automatic `git config\npush.warned_about_default_change true`, then warn forevermore when users\npush from a repo with neither that option nor a push.default? This will\nwarn existing users with arbitrarily long upgrade cycles, and reduce the\namount of noise during the (necessarily) already noisy first days of a\nnew repo.\n\nFWIW, I've been stung by the old behaviour and think the change of\ndefault is a great idea, but have nothing more useful to add :)\n\n\t- Andrew\n"},{"id":"187152","messageId":"20120317140030.GA27369@gnu.kitenet.net","threadId":"29973","inReplyTo":"7v7gyjersg.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Joey Hess","fromEmail":"joey@kitenet.net","sentAt":"2012-03-17T14:00:30Z","receivedAt":"2012-03-17T14:00:30Z","isPatch":false,"sender":{"key":"joey@kitenet.net","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"I'd like to point out a use case for the current push behavior\nthat has probably not been considered. I've written several tools\nthat store data on subsidiary git branches. \n\nOne is pristine-tar, in which information necessarily to reconstruct\nbit-identical tarballs containing the source in (say) master is stored\nefficiently in the pristine-tar branch. Another is git-annex, in which\nbookeeping information about the actual location of large files is\nstored in the git-annex branch. These are not unlike git notes, other\nthan not being built into git. I'm not the only one doing this, other\nexamples I know of include several bug trackers (git-case, git-issues,\nticgit).\n\nThe current push behavior works well for these subsidiary branches.\nBut if users have to remember to manually push these branches, which they\ndo not otherwise manually interact with, they'll forget. I know this\nwill be confusing, because with current git, users have to be instructed\nto push these branches *once*, to get the tracking set up.\n\nI feel that this use of subsidiary branches expands the reach of git;\nthere are reasons that Fossil is pulling other ancillary data\n(bugs, wiki, blog etc) into DVCS. But it makes the mistake, IMHO, of\nbundling all that together into one peice of software. Git allows doing\nthe same things, but loosely coupled, so the best implementation of each\ncan win.\n\nThere might be some way to handle such subsidiary branches while\nstill changing the push default. If git prints a good enough warning\nabout other, unpushed matching branches, the user only has to do a\nlittle more work to push them. If a hook was available that could\nadd branches to the set to be pushed, it could automate pushing\nsuch branches. Or git could get a way to mark one branch as a subsidiary\nbranch of another, and automatically include subsidiaries in pushes.\n\n-- \nsee shy jo\n"},{"id":"187170","messageId":"CADVrmKSGbA2gWVyPLMCBay3EikOykwq3eEH1+qWCpZvOron3Aw@mail.gmail.com","threadId":"29973","inReplyTo":"7v7gyjersg.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"fREW Schmidt","fromEmail":"frioux@gmail.com","sentAt":"2012-03-17T18:43:55Z","receivedAt":"2012-03-17T18:43:55Z","isPatch":false,"sender":{"key":"frioux@gmail.com","avatar":"https://gravatar.com/avatar/639ef3cc221c7f2c225568697bc9d42be4d4e3bada6b4a3b9c32685548f3c105?d=mp&s=160"},"body":"On Sat, Mar 17, 2012 at 12:10 AM, Junio C Hamano wrote:\n>\n> There is a proposal to change the default behaviour of 'git push' on the\n> Git mailing list. The goal of this message is to encourage you to discuss\n> it before it happens (or the change is aborted, depending on the outcome\n> of the discussion).\n\nI personally much prefer the one where it pushes the current branch to\nits tracking branch only. That leaves very little room for surprises\nand mistakes (the one exception being git push after git checkout -b\nnew-branch origin/master.)\n\n--\nfREW Schmidt\nhttp://blog.afoolishmanifesto.com\n"},{"id":"187194","messageId":"4F655E53.6030408@zytor.com","threadId":"29973","inReplyTo":"CADVrmKSGbA2gWVyPLMCBay3EikOykwq3eEH1+qWCpZvOron3Aw@mail.gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2012-03-18T04:02:27Z","receivedAt":"2012-03-18T04:02:27Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On 03/17/2012 11:43 AM, fREW Schmidt wrote:\n> On Sat, Mar 17, 2012 at 12:10 AM, Junio C Hamano wrote:\n>>\n>> There is a proposal to change the default behaviour of 'git push' on the\n>> Git mailing list. The goal of this message is to encourage you to discuss\n>> it before it happens (or the change is aborted, depending on the outcome\n>> of the discussion).\n> \n> I personally much prefer the one where it pushes the current branch to\n> its tracking branch only. That leaves very little room for surprises\n> and mistakes (the one exception being git push after git checkout -b\n> new-branch origin/master.)\n> \n\nI would agree with this being the least surprising behavior. I believe\nthis is what push.default = upstream does.\n\n\t-hpa\n"},{"id":"187197","messageId":"CAMkPkZVuW-5=o=pdfrymVkPu3k_DS1DDH_wuGXoXnq3=Z+LN_w@mail.gmail.com","threadId":"29973","inReplyTo":"4F655E53.6030408@zytor.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Marcus D. Hanwell","fromEmail":"marcus.hanwell@kitware.com","sentAt":"2012-03-18T05:43:43Z","receivedAt":"2012-03-18T05:43:43Z","isPatch":false,"sender":{"key":"marcus.hanwell@kitware.com","avatar":null},"body":"On Sun, Mar 18, 2012 at 12:02 AM, H. Peter Anvin wrote:\n> On 03/17/2012 11:43 AM, fREW Schmidt wrote:\n>> On Sat, Mar 17, 2012 at 12:10 AM, Junio C Hamano wrote:\n>>>\n>>> There is a proposal to change the default behaviour of 'git push' on the\n>>> Git mailing list. The goal of this message is to encourage you to discuss\n>>> it before it happens (or the change is aborted, depending on the outcome\n>>> of the discussion).\n>>\n>> I personally much prefer the one where it pushes the current branch to\n>> its tracking branch only.  That leaves very little room for surprises\n>> and mistakes (the one exception being git push after git checkout -b\n>> new-branch origin/master.)\n>>\n>\n> I would agree with this being the least surprising behavior.  I believe\n> this is what push.default = upstream does.\n>\nI agree that the least surprising default is to push the current\nbranch to its tracking branch only. It always surprised me that other\nbranches tried to push too.\n\nMarcus\n"},{"id":"187210","messageId":"4F6612E3.5040600@gmail.com","threadId":"29973","inReplyTo":"CADVrmKSGbA2gWVyPLMCBay3EikOykwq3eEH1+qWCpZvOron3Aw@mail.gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2012-03-18T16:52:51Z","receivedAt":"2012-03-18T16:52:51Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On 17.03.2012 19:43, fREW Schmidt wrote:\n\n> its tracking branch only. That leaves very little room for surprises\n> and mistakes (the one exception being git push after git checkout -b\n> new-branch origin/master.)\n\nThat's exactly why I'd prefer \"current\" instead of \"upstream\" as the \ndefault behavior, as it even causes no surprises in the checkout -b \ncase, IMHO.\n\nI believe the most common workflow for the large number of git users who \nare no integrators / maintainers is to start a topic branch from master \nand then work on that topic branch until it gets merged. In order to \ntest the topic branch on other platforms or make it available to others, \nit's a common operation to push the topic branch to a branch of the same \nname instead of the tracking branch. That's why I believe \"current\" is \nboth the setting that matches the workflow of most git users and is the \nsetting that really causes the least surprises (not least because it's \nstraight forward what the name of the pushed branch would be, as it's \nthe current branch's name; if you don't know the upstream branch's name \nout of your head, you'd have to look it up to know).\n\n-- \nSebastian Schuberth\n"},{"id":"187211","messageId":"7vipi1d9r7.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"4F6461D7.40303@pileofstuff.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-18T18:50:04Z","receivedAt":"2012-03-18T18:50:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Sayers writes:\n\n> On 17/03/12 05:22, Junio C Hamano wrote:\n>> If the conclusion of the discussion is that we will change the default,\n>> the transition to the new default will go like this:\n>> \n>> 1. An announcement message to let the user communities know about the\n>> future change will be distributed in a way similar to the previous\n>> request-for-discussion message was distributed.\n>> \n>> 2. The first version of Git that is released after such an announcement\n>> will start issuing a warning ...\n>> \n>> 3. We wait for a few release cycles.\n>> \n>> 4. The default changes. ... \n>> The warning message will be reworded ...\n>> being the 'matching' in the future\", it will say \"has changed to X\".\n>> \n>> 5. We wait for a few release cycles.\n>> \n>> 6. The warning is removed.\n>> \n>> A typical release cycle lasts for 8-10 weeks.\n> \n> Unfortunately, \"a few release cycles\" strikes me as a rather hopeful\n> description. For example, a user installing the new Ubuntu LTS release\n> (due out next month) would feel completely justified in not upgrading\n> until 2017, whereas the rest of us would get rather bored disabling the\n> same old warning in every new repo we create for the next five years.\n\nThere is nothing hopeful about it.\n\nThe point of a release like LTS is to shield the users of the distribution\nfrom what happens in upstream, so it is up to the distro to help users. We\ndo not have a way to help their users in a direct way, other than letting\nthe distro know about the change, and educate the distros how they help\ntheir users.\n\nIf I were a user of such a distro whose sole point is a long term support,\nI would expect that a LTS that was originally released before point #2\nwhose lifespan extends beyond point #6 to backport only the \"warning\"\nchanges to such a release between #2 and #6 timespan as a point update to\nsuch a LTS release. Otherwise the distro is actively doing a disservice to\nits users. Such a distro can also choose to revert the \"warning removal\"\nchange #6 in their binary when they release a new LTS. If they did not\nbackport \"add warning\" to their earlier LTS release, that is at least what\nthey can do to help their users.\n\nBut again, that is not something we have direct control over, and it is\nnot very useful to discuss this on this list. Ubuntu LTS support forum\nmight be a better place, but in short, it is not a problem we can solve\n(nor we should be solving), as long as we have a reasonable migration plan\nand if the user is locked out of that migration plan---whoever is doing\nthe locking-out is taking responsibility for these users who are out of\nour reach.\n"},{"id":"187215","messageId":"CACBZZX6_m6b3Abf=NhWvL_g5aHEG9xZEBFfc3K35aSRrUBeWOQ@mail.gmail.com","threadId":"29973","inReplyTo":"7vipi1d9r7.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2012-03-18T21:26:25Z","receivedAt":"2012-03-18T21:26:25Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Mar 18, 2012 at 19:50, Junio C Hamano wrote:\n\n> But again, that is not something we have direct control over [...]\n> ---whoever is doing the locking-out is taking responsibility for\n> these users who are out of our reach.\n\nFirstly I'm all for this change, but I agree with Andrew Sayers that\nstep the deprecation plan is somewhat questionable.\n\nI contribute to the perl core and a few years ago we moved to make\nyearly releases, at the same time we introduced a deprecation cycle\nsaying that if we warn that something will be removed in $YEAR it's\nkosher to remove it in $YEAR+2.\n\nThe problem with that approach is that as Andrew points out OS release\ncycles aren't yearly, so someone might upgrade from $YEAR-2 to YEAR+3\nand find that his programs don't compile anymore.\n\nGit is similar to Perl in that most of our users don't get Git from us\nwith any regular interval, they just use whatever's packaged by their\nOS, and in practice:\n\n * Most of your users use your program through their OS vendor\n\n * OS vendors will upgrade their OS whenever they feel like it.\n\n * OS vendors are in all likelyhood not going to backport some\n deprecation patch or eject it from their build in a manner that\n makes sense with regard to their release schedule.\n\nThat sucks, but given that this is how things work I wonder who we're\nreally helping by implementing deprecation warnings from the\nstandpoint of our release cycle, probably not the majority of our\nusers.\n\nMost of our users are either never going to see this warning because\ntheir OS will skip the whole of steps 2-6, or worse yet their OS\nmight upgrade Git between steps 2-5 and they'll be stuck watching the\nwarning it for 1-6 years, or however long their upstream vendor takes\nup upgrade.\n\nI think a better strategy would be to just announce that we're going\nto change it, and then just change it without any intermediate\nsteps. That's what this is going to look like anyway to most of our\nusers, and without the danger that our users will be stuck on releases\nthat'll spew warnings about some upcoming change which in reality\nhappened in upstream years ago.\n\nWe could even use the only way of communicating to everyone involved\nthat something major changed: bump the major version number.\n"},{"id":"187227","messageId":"7v3995cu0s.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"CACBZZX6_m6b3Abf=NhWvL_g5aHEG9xZEBFfc3K35aSRrUBeWOQ@mail.gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-19T00:29:55Z","receivedAt":"2012-03-19T00:29:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Most of our users are either never going to see this warning because\n> their OS will skip the whole of steps 2-6, or worse yet their OS\n> might upgrade Git between steps 2-5 and they'll be stuck watching the\n> warning it for 1-6 years, or however long their upstream vendor takes\n> up upgrade.\n>\n> I think a better strategy would be to just announce that we're going\n> to change it, and then just change it without any intermediate\n> steps.\n\nYou are only arguing that what we do does not matter much to Distro users,\nand you already read that I agreed with that. It's really up to the distro\nto make sure their release cycle does not harm the users.\n\nBut does that mean we won't have to help our own users who do not depend\non distros with a gentler approach? I don't think so.\n\nJust like we say we would want to see Perl 5.8.3 or newer for unicode\npurposes, it would be sufficient if our announce says Git 1.8.x and later\ngives an updated default behaviour to help new people by avoiding a harder\nto understand error modes when used in the simplest workflow.\n"},{"id":"187228","messageId":"7vy5qxbf5r.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"20120317140030.GA27369@gnu.kitenet.net","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-19T00:36:16Z","receivedAt":"2012-03-19T00:36:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joey Hess writes:\n\n> ... I know this\n> will be confusing, because with current git, users have to be instructed\n> to push these branches *once*, to get the tracking set up.\n\nWell, a tool like git-annex is not the primary audience to choose the\ndefault behaviour for \"git push\" without configuration. Instead of\ninstructing \"to push *once*\", you can easily instruct to install\nremote.$name.push that covers the primary and subsidiary branches.\n\nAlternatively \"git annex push\" could drive the underlying \"git push\" in\nwhatever way it wishes. Notice a branch is being pushed, and then add its\nsubsidiary branch to the set of refs to be pushed (because it, not Git, is\nthe one who knows the correspondence between the primary branch and the\nsubsidiary branch).\n"},{"id":"187240","messageId":"CAAGHeXEsfVPDY+t+ynz0d7HQjsi2ZTMJaNjbT4+t5sS-RL6Jag@mail.gmail.com","threadId":"29973","inReplyTo":"7v3995cu0s.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Sebastien Douche","fromEmail":"sdouche@gmail.com","sentAt":"2012-03-19T07:29:03Z","receivedAt":"2012-03-19T07:29:03Z","isPatch":false,"sender":{"key":"sdouche@gmail.com","avatar":"https://gravatar.com/avatar/1b4a6cb11f6237ff9dc78b953ce48e416afa42e947143e14273cdc2c7f6f9c1a?d=mp&s=160"},"body":"On Mon, Mar 19, 2012 at 01:29, Junio C Hamano wrote:\n\nHi Junio\n\n> But does that mean we won't have to help our own users who do not depend\n> on distros with a gentler approach?  I don't think so.\n\nIt's here a very particular change: most users don't use / don't like\nthe default behaviour. Most of them will be happy with this change.\n\n\n-- \nSebastien Douche \nTwitter: @sdouche / G+: +sdouche\n"},{"id":"187242","messageId":"alpine.DEB.2.00.1203190945560.15290@ds9.cixit.se","threadId":"29973","inReplyTo":"7v7gyjersg.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2012-03-19T09:07:10Z","receivedAt":"2012-03-19T09:07:10Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"At $dayjob, our setup instructions for Git do say that everyone setting up a \nnew machine shall run \"git config --global push.default tracking\". This is \nwhat suits our workflow where people work on a topic branch, which they will \npush to and pull from our central repository (each topic branch is owned by \na team of one or more developers). By using \"tracking\", they can just do a\n\n git push\n\nand not have to worry about other half-finished or local changes \"pollute\" \nthe One True Central Repository. We have found that this configuration \nmakes it easier to explain the workflow, especially since it more or less \ndoes make \"push\" the opposite of \"pull\" (both of them just updating one \n\"real\" branch on either side).\n\nWe also have cases where we work on different repositories, with different \ncodebases; we have an upstream codebase that is merged into one or more \ndownstream codebases, and sometimes we have branches that are used with more \nthan one codebase (pull branch A from upstream repo, merge with downstream \nrepo and work with it there). Or we work on cross-codebase maintainence \n(transplant fix on branch A from codebase B to codebase C). We have \ninstalled hooks on our repositories that try to make sure history does \nnot get pushed to the wrong repository -- as could sometimes happen if \nyou had a branch checked out locally from the another codebase and forgot \nto configure your push.default.\n\n\nI have also personally found that this is the setting that I do feel most \ncomfortable with in more or less every other context where I work with Git, \nso I do think this would be a fairly useful default value.\n\n\nI know the policy in Git is to not allow the remote repository dictate \nanything about the configuration in the local repository, but as an \nalternative to changing the \"push.default\" value, perhaps we should allow \nsetting some configuration option on the remote repository that blocks it \nfrom being the target of a \"push.default = matching\" push?\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"187243","messageId":"20120319093505.GA10017@burratino","threadId":"29973","inReplyTo":"alpine.DEB.2.00.1203190945560.15290@ds9.cixit.se","subject":"Letting remote repositories override local configuration","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-03-19T09:35:05Z","receivedAt":"2012-03-19T09:35:05Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Peter Krefting wrote:\n\n> I know the policy in Git is to not allow the remote repository\n> dictate anything about the configuration in the local repository,\n> but as an alternative to changing the \"push.default\" value, perhaps\n> we should allow setting some configuration option on the remote\n> repository that blocks it from being the target of a \"push.default =\n> matching\" push?\n\nIf I work for your company and always keep all my local topic branches\nin good order, I would expect to be permitted to use \"push.default =\nmatching\" to easily push them all at once after I have finished\npreparing them, provided I have set up my local copy of git that way\nexplicitly, regardless of what the person setting up the\ninfrastructure thought.\n\nWhat would I be missing?\n\nCurious,\nJonathan\n"},{"id":"187249","messageId":"alpine.DEB.2.00.1203191319360.15290@ds9.cixit.se","threadId":"29973","inReplyTo":"20120319093505.GA10017@burratino","subject":"Re: Letting remote repositories override local configuration","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2012-03-19T12:21:33Z","receivedAt":"2012-03-19T12:21:33Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Jonathan Nieder:\n\n> What would I be missing?\n\nIf you can manage to do that and never mis-push, then, yes, that would be \nfine. As soon as you have local branches checked out it starts getting \nproblematic; we also have different servers with different branch namespaces \nthat we push to, and making sure the wrong branch doesn't get pushed to the \nwrong server can sometimes be difficult.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"187273","messageId":"87BE88BA-2827-4EDC-99BF-94026E604AB0@sb.org","threadId":"29973","inReplyTo":"7v7gyjersg.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2012-03-19T18:57:16Z","receivedAt":"2012-03-19T18:57:16Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"I would love to see the default changed to 'upstream'. I've wanted this ever\nsince the push.default=tracking value was introduced. When introducing new\nusers to git, one of the first things I always tell them is to run\n\n git config --global push.default tracking\n\nbecause it's far easier to explain how that behavior works than it is to\nexplain how the 'matching' behavior works, and it more closely aligns with\nthe way people (in my experience) typically use git.\n\n-Kevin\n\nOn Mar 16, 2012, at 10:10 PM, Junio C Hamano wrote:\n\n> There is a proposal to change the default behaviour of 'git push' on the\n> Git mailing list. The goal of this message is to encourage you to discuss\n> it before it happens (or the change is aborted, depending on the outcome\n> 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 the\n> same name. This is usually appropriate when a developer pushes to his own\n> public repository, but may be confusing if not dangerous when using a\n> shared repository. The proposal is to change the default to 'upstream',\n> i.e. push only the current branch, and push it to the branch 'git pull'\n> would pull from. Another candidate is 'current'; this pushes only the\n> current branch to the remote branch of the same name.\n> \n> For more details on the behavior of Git with these values, read the\n> 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 do not\n> see anything in the output from 'git config push.default' and if you rely\n> on the default that pushes all your matching branches. On the other hand,\n> you may want to see the default behaviour to change, especially if you are\n> using shared repositories. In either case, please join the discussion to\n> give us more data point and help us decide the future of Git. Also, if\n> you think your friends and colleagues will be affected by this change,\n> either positively or negatively, please tell them about this discussion.\n> \n> What has been discussed so far can be seen in this thread:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694\n> \n> Previous relevant discussions include:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541\n> http://thread.gmane.org/gmane.comp.version-control.git/166743\n> \n> To join the discussion, send your messages to:\n> \n> git@vger.kernel.org\n> \n> The list accepts messages from non-subscribers, and you do not have to ask\n> \"please Cc me, I am not subscribed\", as it's customary to Cc: posters when\n> replying on this list.\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":"187274","messageId":"4F6792DE.80208@pileofstuff.org","threadId":"29973","inReplyTo":"7vipi1d9r7.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-03-19T20:11:10Z","receivedAt":"2012-03-19T20:11:10Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 18/03/12 18:50, Junio C Hamano wrote:\n> Andrew Sayers writes:\n> \n>> On 17/03/12 05:22, Junio C Hamano wrote:\n>>> If the conclusion of the discussion is that we will change the default,\n>>> the transition to the new default will go like this:\n>>>\n>>> 1. An announcement message to let the user communities know about the\n>>> future change will be distributed in a way similar to the previous\n>>> request-for-discussion message was distributed.\n>>>\n>>> 2. The first version of Git that is released after such an announcement\n>>> will start issuing a warning ...\n>>>\n>>> 3. We wait for a few release cycles.\n>>>\n>>> 4. The default changes. ... \n>>> The warning message will be reworded ...\n>>> being the 'matching' in the future\", it will say \"has changed to X\".\n>>>\n>>> 5. We wait for a few release cycles.\n>>>\n>>> 6. The warning is removed.\n>>>\n>>> A typical release cycle lasts for 8-10 weeks.\n>>\n>> Unfortunately, \"a few release cycles\" strikes me as a rather hopeful\n>> description. For example, a user installing the new Ubuntu LTS release\n>> (due out next month) would feel completely justified in not upgrading\n>> until 2017, whereas the rest of us would get rather bored disabling the\n>> same old warning in every new repo we create for the next five years.\n> \n> There is nothing hopeful about it.\n> \n> The point of a release like LTS is to shield the users of the distribution\n> from what happens in upstream, so it is up to the distro to help users. We\n> do not have a way to help their users in a direct way, other than letting\n> the distro know about the change, and educate the distros how they help\n> their users.\n> \n> If I were a user of such a distro whose sole point is a long term support,\n> I would expect that a LTS that was originally released before point #2\n> whose lifespan extends beyond point #6 to backport only the \"warning\"\n> changes to such a release between #2 and #6 timespan as a point update to\n> such a LTS release. Otherwise the distro is actively doing a disservice to\n> its users. Such a distro can also choose to revert the \"warning removal\"\n> change #6 in their binary when they release a new LTS. If they did not\n> backport \"add warning\" to their earlier LTS release, that is at least what\n> they can do to help their users.\n> \n> But again, that is not something we have direct control over, and it is\n> not very useful to discuss this on this list. Ubuntu LTS support forum\n> might be a better place, but in short, it is not a problem we can solve\n> (nor we should be solving), as long as we have a reasonable migration plan\n> and if the user is locked out of that migration plan---whoever is doing\n> the locking-out is taking responsibility for these users who are out of\n> our reach.\n> \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> \n\nI take the point that distros have their own support infrastructure, so\nperhaps this would be a better example:\n\nMany administrators in corporate environments will install git from\nsource, because they don't trust RPM/need some feature in the latest\nversion/are just that way inclined. Having installed it, they tend to\nsit on that version for a few years until they have to upgrade the\nsystem/need some feature in the new latest version/are still just that\nway inclined. Their justification for not upgrading is often that new\nversions of software tend to change behaviour in subtle ways that break\nthe scripts they've bodged together over the years. Trying to argue\nthat one particular bit of software will only hurt you if you wait for\nthe wrong amount of time tends to be a losing battle, because\nadministrators hate special cases just as much as programmers.\n\nHaving said all that, here's a slightly different argument for a\nslightly better solution:\n\nWhen a user upgrades to a mid- or post-change version of git, I think\nit's a good idea for them to be warned about the change of behaviour.\nBut new users, and old users with new repositories, gain nothing from\nthe little history lesson. This should be solved in git itself, because\ntwo users of the same binary might expect different behaviour. An\nautomatic `git config push.default ` at repository creation\ntime would silence the noise without disrupting the signal. As an added\nbonus, this approach might take some heat out of the argument when the\numpteenth \"is it time to remove the warning yet?\" thread kicks off.\n\n\t- Andrew\n"},{"id":"187284","messageId":"7v62e09sig.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"4F6792DE.80208@pileofstuff.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-19T21:43:03Z","receivedAt":"2012-03-19T21:43:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Sayers writes:\n\n> On 18/03/12 18:50, Junio C Hamano wrote:\n>> \n>> ... but in short, it is not a problem we can solve\n>> (nor we should be solving), as long as we have a reasonable migration plan\n>> and if the user is locked out of that migration plan---whoever is doing\n>> the locking-out is taking responsibility for these users who are out of\n>> our reach.\n>\n> I take the point that distros have their own support infrastructure, so\n> perhaps this would be a better example:\n>\n> Many administrators in corporate environments will install git from\n> source, because they don't trust RPM/need some feature in the latest\n> version/are just that way inclined. Having installed it, they tend to\n> sit on that version for a few years ...\n\nThe same response applies. These administrators are taking responsibility\nfor their users by making them out of our reach.\n\n> ... a\n> slightly better solution:\n>\n> When a user upgrades to a mid- or post-change version of git, I think\n> it's a good idea for them to be warned about the change of behaviour.\n> But new users, and old users with new repositories, gain nothing from\n> the little history lesson.\n\nYou are right for new users, but are wrong for old users who aren't aware\nof the switch-over, *and* are harmed by the switch-over.\n"},{"id":"187286","messageId":"CANgJU+VF-3LnwkrWgSQ1r50R=zjw8vsK1G686OqetSUGHuFcfw@mail.gmail.com","threadId":"29973","inReplyTo":"7v62e09sig.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-03-19T22:20:28Z","receivedAt":"2012-03-19T22:20:28Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 19 March 2012 22:43, Junio C Hamano wrote:\n> Andrew Sayers writes:\n>\n>> On 18/03/12 18:50, Junio C Hamano wrote:\n>>>\n>>> ... but in short, it is not a problem we can solve\n>>> (nor we should be solving), as long as we have a reasonable migration plan\n>>> and if the user is locked out of that migration plan---whoever is doing\n>>> the locking-out is taking responsibility for these users who are out of\n>>> our reach.\n>>\n>> I take the point that distros have their own support infrastructure, so\n>> perhaps this would be a better example:\n>>\n>> Many administrators in corporate environments will install git from\n>> source, because they don't trust RPM/need some feature in the latest\n>> version/are just that way inclined.  Having installed it, they tend to\n>> sit on that version for a few years ...\n>\n> The same response applies. These administrators are taking responsibility\n> for their users by making them out of our reach.\n>\n>> ... a\n>> slightly better solution:\n>>\n>> When a user upgrades to a mid- or post-change version of git, I think\n>> it's a good idea for them to be warned about the change of behaviour.\n>> But new users, and old users with new repositories, gain nothing from\n>> the little history lesson.\n>\n> You are right for new users, but are wrong for old users who aren't aware\n> of the switch-over, *and* are harmed by the switch-over.\n\nWhat is your definition of \"harmed\" in this case? I do not see how a\nchange like this could cause harm. I can see how it could cause\ndisharmony, but that is not the same. I thought the worse case here is\nminor inconvenience, not data loss or anything else that is obviously\nharmful.\n\ncheers,\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"187289","messageId":"7v1uoo9pyo.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"CANgJU+VF-3LnwkrWgSQ1r50R=zjw8vsK1G686OqetSUGHuFcfw@mail.gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-19T22:38:07Z","receivedAt":"2012-03-19T22:38:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"demerphq writes:\n\n> ... I thought the worse case here is\n> minor inconvenience, not data loss or anything else that is obviously\n> harmful.\n\nIf your definition of harm is limited to data loss then we wouldn't be\ntalking about updating the default from matching to current or upstream.\n\"If your push failed, pushed what you did not mean to, or did not push\nwhat you meant to, you would correct the mistake\" applies equally to a new\nperson who expected \"current\" (or \"upstream\") and got \"matching\", or an old\nperson who expected \"matching\" and got \"current\".\n\nThe purpose of the default change is to reduce surprises to people who\nhaven't yet learned Git too well. And for them,\n\n I was on master, I said 'git push' without saying what to push to\n where, and it resulted in master updated at the central repository.\n\nis the least surprising outcome. Note that a learnt Git user would not\nexpress what he did this way; he will say 'I was on *my* master' and\n'the master at the central repository was updated with *my* master', but\nthe change of the default is to help those who haven't even learned that\nyour branches and branches at the central server are not always connected.\n\nChoice of \"upstream\" is more convenient for users who learned Git a bit\nmore and knows the distinction between branches you have and branches the\ncentral server has. For them, \"I was on my 'topic' branch, that was\nforked from the 'master' branch at the central repository. I said 'git\npush', and I updated the 'master' over there with my 'topic'\", is also not\nsurprising, but it is more advanced audience than those helped by the\ndefault setting to push 'current'.\n\nIn either way, once people learn sufficiently to the point that they can\nchoose their own default that suit them, there is no need for handholding.\nThey won't be surprised.\n\nBut except for one case you should *not* forget about.\n\nThe ones who get pulled the old default under their feet while not paying\ntoo much attention to this discussion. The change will hit them with a\nsurprise, and that is what I am trying to avoid here.\n"},{"id":"187291","messageId":"4F67B78B.6080208@pileofstuff.org","threadId":"29973","inReplyTo":"7v62e09sig.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-03-19T22:47:39Z","receivedAt":"2012-03-19T22:47:39Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 19/03/12 21:43, Junio C Hamano wrote:\n> Andrew Sayers writes:\n> \n>> On 18/03/12 18:50, Junio C Hamano wrote:\n>>>\n>>> ... but in short, it is not a problem we can solve\n>>> (nor we should be solving), as long as we have a reasonable migration plan\n>>> and if the user is locked out of that migration plan---whoever is doing\n>>> the locking-out is taking responsibility for these users who are out of\n>>> our reach.\n>>\n>> I take the point that distros have their own support infrastructure, so\n>> perhaps this would be a better example:\n>>\n>> Many administrators in corporate environments will install git from\n>> source, because they don't trust RPM/need some feature in the latest\n>> version/are just that way inclined. Having installed it, they tend to\n>> sit on that version for a few years ...\n> \n> The same response applies. These administrators are taking responsibility\n> for their users by making them out of our reach.\n> \n\nI'm not sure I follow. It sounds like you're saying we should avoid\nhelping anyone that doesn't stick to our upgrade schedule, but that\nwould mean it's redundant to add code at all - all the publicity this\nchange has got means everyone close enough to the process has heard\nabout it already.\n\n>> ... a\n>> slightly better solution:\n>>\n>> When a user upgrades to a mid- or post-change version of git, I think\n>> it's a good idea for them to be warned about the change of behaviour.\n>> But new users, and old users with new repositories, gain nothing from\n>> the little history lesson.\n> \n> You are right for new users, but are wrong for old users who aren't aware\n> of the switch-over, *and* are harmed by the switch-over.\n\nYou're right that the solution I suggested would harm people who\nregularly create new repositories, but have written scripts that expect\nthe old behaviour in those new repositories. The only solution that\nwould completely avoid harming that small group would be to permanently\nmake the default push.default \"print a warning and give up\" - otherwise\nyou're just harming people with long schedules instead of those with\nshort ones.\n\n\t- Andrew\n"},{"id":"187292","messageId":"7vsjh48af1.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"4F67B78B.6080208@pileofstuff.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-19T22:59:14Z","receivedAt":"2012-03-19T22:59:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Sayers writes:\n\n> On 19/03/12 21:43, Junio C Hamano wrote:\n>> \n>> The same response applies. These administrators are taking responsibility\n>> for their users by making them out of our reach.\n>\n> I'm not sure I follow. It sounds like you're saying we should avoid\n> helping anyone that doesn't stick to our upgrade schedule,...\n\nI am not saying \"should avoid\". I am saying it is not much use.\n\nAll we can do is to inform, educate and help those who are taking\nresponsibility, be it LTS distro or these administrators, to help their\nusers. I've already outlined what LTS distros could do with backporting\nand reverting in the previous message.\n\nWe can make sure that the \"default flip\" and \"stop warn\" patches can be\neasily cherry-picked by them, even though we cannot force them to do so.\n"},{"id":"187299","messageId":"4F67EB1F.30205@gmail.com","threadId":"29973","inReplyTo":"7v7gyjersg.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Antony Male","fromEmail":"antony.male@gmail.com","sentAt":"2012-03-20T02:27:43Z","receivedAt":"2012-03-20T02:27:43Z","isPatch":false,"sender":{"key":"antony.male@gmail.com","avatar":"https://gravatar.com/avatar/44ebc98c2d05837be689ed72514f8119844424a9cf099e5202be4190281982f1?d=mp&s=160"},"body":"This is my 2 cents from helping out on #git. I don't consider workflows \nat all, only how to minimise confusion for new users when they're trying \nto understand how git works.\n\nWe occasionally get users who are having trouble understanding why the \nargument-less form of 'git pull' is failing, due to lack of tracking \nconfiguration. We explain that the tracking config is git's way of \n\"connecting\" local and remote branches, and how to use 'git push -u' and \n'git branch --set-upstream' appropriately.\n\nThis is all well and good -- they've discovered that local and remote \nbranches are separate, that they aren't \"magically\" joined, that there's \na bit of configuration data which \"connects\" the two, and how to \nmanipulate it.\n\nUsers then assume that argument-less form of 'git push' uses the same \nmechanism. To then discover that it (by default) uses a different way \nof \"connecting\" local and remote branches is often confusing [1]. In \naddition, it can't be manipulated in the same way as the tracking config \nthey learnt about before.\n\nFor this reason, I am in favour of push.default = upstream. Although it \nrequires knowledge about setting up tracking config (in the cases where \ntracking config isn't set automatically), this knowledge has to be \ngained anyway for the argument-less form of 'git pull' to work.\n\n\n[1]: Indeed, a lot of users only find out about this difference when it \nhas bitten them in some way.\n\nThanks,\nAntony\n"},{"id":"187305","messageId":"CA+7g9JzfFg9U9qiWtjX5OgA5c=dS1bPWaXqMbmxAtzaQeKRF8Q@mail.gmail.com","threadId":"29973","inReplyTo":"7v7gyjersg.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Nathan Gray","fromEmail":"n8gray@n8gray.org","sentAt":"2012-03-20T07:13:31Z","receivedAt":"2012-03-20T07:13:31Z","isPatch":false,"sender":{"key":"n8gray@n8gray.org","avatar":"https://avatars.githubusercontent.com/u/82794?v=4"},"body":"On Fri, Mar 16, 2012 at 10:10 PM, Junio C Hamano wrote:\n> There is a proposal to change the default behaviour of 'git push' on the\n> Git mailing list. The goal of this message is to encourage you to discuss\n> it before it happens (or the change is aborted, depending on the outcome\n> 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 the\n> same name. This is usually appropriate when a developer pushes to his own\n> public repository, but may be confusing if not dangerous when using a\n> shared repository. The proposal is to change the default to 'upstream',\n> i.e. push only the current branch, and push it to the branch 'git pull'\n> would pull from. Another candidate is 'current'; this pushes only the\n> current branch to the remote branch of the same name.\n\n+1 for 'upstream'. \"Push\" should mirror \"pull\" by the principle of\nleast surprise.\n\nCheers,\n-Nathan\n\n-- \nhttp://n8gray.org\n"},{"id":"187312","messageId":"4F685559.8040402@op5.se","threadId":"29973","inReplyTo":"7v1uoo9pyo.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-03-20T10:00:57Z","receivedAt":"2012-03-20T10:00:57Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"I just realized I've had the proposed behaviour for \"upstream\" backwards\nall along. I thought \"upstream\" was meant to do what \"matching\" does\ntoday.\n\nI'd like to change my vote to \"upstream\" instead, although I think the\nname for it is truly horrible. Perhaps that's just me though, since\nwe're using \"upstream\" as a remotename for repositories we get from\nafar but work on internally as well.\n\nOn 03/19/2012 11:38 PM, Junio C Hamano wrote:\n> demerphq writes:\n> \n>> ... I thought the worse case here is\n>> minor inconvenience, not data loss or anything else that is obviously\n>> harmful.\n> \n> If your definition of harm is limited to data loss then we wouldn't be\n> talking about updating the default from matching to current or upstream.\n> \"If your push failed, pushed what you did not mean to, or did not push\n> what you meant to, you would correct the mistake\" applies equally to a new\n> person who expected \"current\" (or \"upstream\") and got \"matching\", or an old\n> person who expected \"matching\" and got \"current\".\n> \n> The purpose of the default change is to reduce surprises to people who\n> haven't yet learned Git too well. And for them,\n> \n> I was on master, I said 'git push' without saying what to push to\n> where, and it resulted in master updated at the central repository.\n> \n> is the least surprising outcome. Note that a learnt Git user would not\n> express what he did this way; he will say 'I was on *my* master' and\n> 'the master at the central repository was updated with *my* master', but\n> the change of the default is to help those who haven't even learned that\n> your branches and branches at the central server are not always connected.\n> \n> Choice of \"upstream\" is more convenient for users who learned Git a bit\n> more and knows the distinction between branches you have and branches the\n> central server has. For them, \"I was on my 'topic' branch, that was\n> forked from the 'master' branch at the central repository. I said 'git\n> push', and I updated the 'master' over there with my 'topic'\", is also not\n> surprising, but it is more advanced audience than those helped by the\n> default setting to push 'current'.\n> \n> In either way, once people learn sufficiently to the point that they can\n> choose their own default that suit them, there is no need for handholding.\n> They won't be surprised.\n> \n> But except for one case you should *not* forget about.\n> \n> The ones who get pulled the old default under their feet while not paying\n> too much attention to this discussion. The change will hit them with a\n> surprise, and that is what I am trying to avoid here.\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\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":"187315","messageId":"4F68714D.6030209@spamgourmet.com","threadId":"29973","inReplyTo":"CA+7g9JzfFg9U9qiWtjX5OgA5c=dS1bPWaXqMbmxAtzaQeKRF8Q@mail.gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Ben Tebulin","fromEmail":"nntp.20.jexpert@spamgourmet.com","sentAt":"2012-03-20T12:00:13Z","receivedAt":"2012-03-20T12:00:13Z","isPatch":false,"sender":{"key":"nntp.20.jexpert@spamgourmet.com","avatar":null},"body":"> +1 for 'upstream'. \"Push\" should mirror \"pull\" by the principle of\n> least surprise.\n\nOne more +1 for 'upstream'!\n\nAfter setting up remotes for a branch, 'matching' is convenient, but \nsimply does not match the expectations of a newbie user.\n"},{"id":"187320","messageId":"4F687159.20107@spamgourmet.com","threadId":"29973","inReplyTo":"CA+7g9JzfFg9U9qiWtjX5OgA5c=dS1bPWaXqMbmxAtzaQeKRF8Q@mail.gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Ben Tebulin","fromEmail":"nntp.20.jexpert@spamgourmet.com","sentAt":"2012-03-20T12:00:25Z","receivedAt":"2012-03-20T12:00:25Z","isPatch":false,"sender":{"key":"nntp.20.jexpert@spamgourmet.com","avatar":null},"body":"> +1 for 'upstream'. \"Push\" should mirror \"pull\" by the principle of\n> least surprise.\n\nOne more +1 for 'upstream'!\n\nAfter setting up remotes for a branch, 'matching' is convenient, but \nsimply does not match the expectations of a newbie user.\n"},{"id":"187318","messageId":"4F687168.30007@spamgourmet.com","threadId":"29973","inReplyTo":"CA+7g9JzfFg9U9qiWtjX5OgA5c=dS1bPWaXqMbmxAtzaQeKRF8Q@mail.gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Ben Tebulin","fromEmail":"nntp.20.jexpert@spamgourmet.com","sentAt":"2012-03-20T12:00:40Z","receivedAt":"2012-03-20T12:00:40Z","isPatch":false,"sender":{"key":"nntp.20.jexpert@spamgourmet.com","avatar":null},"body":"> +1 for 'upstream'. \"Push\" should mirror \"pull\" by the principle of\n> least surprise.\n\nOne more +1 for 'upstream'!\n\nAfter setting up remotes for a branch, 'matching' is convenient, but \nsimply does not match the expectations of a newbie user.\n"},{"id":"187319","messageId":"4F687193.7070504@spamgourmet.com","threadId":"29973","inReplyTo":"CA+7g9JzfFg9U9qiWtjX5OgA5c=dS1bPWaXqMbmxAtzaQeKRF8Q@mail.gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Ben Tebulin","fromEmail":"nntp.20.jexpert@spamgourmet.com","sentAt":"2012-03-20T12:01:23Z","receivedAt":"2012-03-20T12:01:23Z","isPatch":false,"sender":{"key":"nntp.20.jexpert@spamgourmet.com","avatar":null},"body":"> +1 for 'upstream'. \"Push\" should mirror \"pull\" by the principle of\n> least surprise.\n\nOne more +1 for 'upstream'!\n\nAfter setting up remotes for a branch, 'matching' is convenient, but \nsimply does not match the expectations of a newbie user.\n"},{"id":"187317","messageId":"m3y5qv32d9.fsf@localhost.localdomain","threadId":"29973","inReplyTo":"4F67EB1F.30205@gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-20T12:04:22Z","receivedAt":"2012-03-20T12:04:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Antony Male writes:\n\n> This is my 2 cents from helping out on #git. I don't consider\n> workflows at all, only how to minimise confusion for new users when\n> they're trying to understand how git works.\n> \n> We occasionally get users who are having trouble understanding why the\n> argument-less form of 'git pull' is failing, due to lack of tracking\n> configuration. We explain that the tracking config is git's way of\n> \"connecting\" local and remote branches, and how to use 'git push -u'\n> and 'git branch --set-upstream' appropriately.\n> \n> This is all well and good -- they've discovered that local and remote\n> branches are separate, that they aren't \"magically\" joined, that\n> there's a bit of configuration data which \"connects\" the two, and how\n> to manipulate it.\n> \n> Users then assume that argument-less form of 'git push' uses the same\n> mechanism. To then discover that it (by default) uses a different way\n> of \"connecting\" local and remote branches is often confusing [1].\n[...]\n\nThe \"matching\" behavior is intende for non-symmetrical situation of a\nworkflow where each user has its own separate public publishing\nrepository, but can pull from many repositories from other developers\n(but never from one's own).\n\nThe situation is assymetrical (even more that \"pull\" and \"push\" for\nsingle upstream repository, in a shared central repository case), so\nconfiguration is assymetrical.\n\n-- \nJakub Narebski\n"},{"id":"187324","messageId":"CAA-BDhymmeQcjPuMatkDfgZzaV3h1ZHPs_t_grVn87oqGABB-w@mail.gmail.com","threadId":"29973","inReplyTo":"7v7gyjersg.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Filipe Fernandes","fromEmail":"ffernand.list@gmail.com","sentAt":"2012-03-20T12:36:27Z","receivedAt":"2012-03-20T12:36:27Z","isPatch":false,"sender":{"key":"ffernand.list@gmail.com","avatar":null},"body":"On Sat, Mar 17, 2012 at 1:10 AM, Junio C Hamano wrote:\n> There is a proposal to change the default behaviour of 'git push' on the\n> Git mailing list. The goal of this message is to encourage you to discuss\n> it before it happens (or the change is aborted, depending on the outcome\n> of the discussion).\n\n+1 on changing the default to 'upstream'.\n\nHaving the same branch name on remote vs local repo shouldn't mean\nthey're necessarily the same branch (as what would be assumed with\n'matching'). Also being explicit beforehand what remote branch the\nlocal branch points to removes all doubt as it what 'git push' should\nbe doing for the owner of the local repo.\n\nregards,\nfilipe\n"},{"id":"187326","messageId":"4F688063.8080802@gmail.com","threadId":"29973","inReplyTo":"m3y5qv32d9.fsf@localhost.localdomain","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Antony Male","fromEmail":"antony.male@gmail.com","sentAt":"2012-03-20T13:04:35Z","receivedAt":"2012-03-20T13:04:35Z","isPatch":false,"sender":{"key":"antony.male@gmail.com","avatar":"https://gravatar.com/avatar/44ebc98c2d05837be689ed72514f8119844424a9cf099e5202be4190281982f1?d=mp&s=160"},"body":"On 20/03/2012 12:04 pm, Jakub Narebski wrote:\n> The \"matching\" behavior is intende for non-symmetrical situation of a\n> workflow where each user has its own separate public publishing\n> repository, but can pull from many repositories from other developers\n> (but never from one's own).\n>\n> The situation is assymetrical (even more that \"pull\" and \"push\" for\n> single upstream repository, in a shared central repository case), so\n> configuration is assymetrical.\n\nSorry, I wasn't clear enough. I'm well aware of why 'matching' and \n'current' exist, and the workflows for which they're suited.\n\nMy point is that these bite new users before they've got to the point of \ndeveloping workflows involving more than one remote. At that point, \nthey're not aware of the need for an asymmetric config, so they're not \nexpecting it to be the default.\n\nTo take another angle on it, I'd rather our new users said \"Hey, there's \nan awesome config option that makes git play nicely with asymmetric \nworkflows\" than \"Why on earth do pull and push interact with different \nremote branches by default\".\n\nThanks,\nAntony\n"},{"id":"187330","messageId":"CACPiFCKbfgSZMnpc6Q_Lg6n5YMHQ2bad-bwQsyASk0eMuiAFTQ@mail.gmail.com","threadId":"29973","inReplyTo":"7vty1ndcoi.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2012-03-20T14:12:28Z","receivedAt":"2012-03-20T14:12:28Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Sat, Mar 17, 2012 at 1:22 AM, Junio C Hamano wrote:\n> If the conclusion of the discussion is that we will change the default,\n> the transition to the new default will go like this:\n\nI am in general agreement with the course of action outlined. There is\none little thing I had expected in addition, that is not discussed:\n\n --force should change behaviour, immediately, to \"current\" or even\nnone (forcing the user to name the remote and branch explicitly).\n\nThe potential for messups with --force combined with \"matching\" and a\nrepo that allows it is considerable. And I cannot imagine any\nmainstream use cases for --force defaulting to matching; at least none\nimportant enough to counterbalance the damage.\n\ncheers,\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- Software Architect - OLPC\n - ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"187331","messageId":"7vy5qv70mh.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"CACPiFCKbfgSZMnpc6Q_Lg6n5YMHQ2bad-bwQsyASk0eMuiAFTQ@mail.gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-20T15:28:22Z","receivedAt":"2012-03-20T15:28:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff writes:\n\n> --force should change behaviour, immediately, to \"current\" or even none\n> (forcing the user to name the remote and branch explicitly).\n\nAny \"immediately\" change is never going to happen merely based on \"I\ncannot imagine in what use case it is useful\".\n\nAs many people already said in the discussion before the RFD message that\nis at the root of this thread, the name of the option --force alone\nalready signals it is something you use after thinking twice.\n"},{"id":"187337","messageId":"m3ty1j2pg4.fsf@localhost.localdomain","threadId":"29973","inReplyTo":"CACPiFCKbfgSZMnpc6Q_Lg6n5YMHQ2bad-bwQsyASk0eMuiAFTQ@mail.gmail.com","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-20T16:43:26Z","receivedAt":"2012-03-20T16:43:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Martin Langhoff writes:\n> On Sat, Mar 17, 2012 at 1:22 AM, Junio C Hamano wrote:\n\n> > If the conclusion of the discussion is that we will change the default,\n> > the transition to the new default will go like this:\n> \n> I am in general agreement with the course of action outlined. There is\n> one little thing I had expected in addition, that is not discussed:\n> \n> --force should change behaviour, immediately, to \"current\" or even\n> none (forcing the user to name the remote and branch explicitly).\n> \n> The potential for messups with --force combined with \"matching\" and a\n> repo that allows it is considerable. And I cannot imagine any\n> mainstream use cases for --force defaulting to matching; at least none\n> important enough to counterbalance the damage.\n\nWell, one can always use\n\n git push +:\n\ninstead of\n\n git push --force\n\nfor \"matching\" push... but I think you would have to provide name of\nrepository.\n\n-- \nJakub Narebski\n"},{"id":"187349","messageId":"CACPiFCLbTA=AwymUOde43Z61t9cd5O=uk_hs5Dt6WZhYYg06zA@mail.gmail.com","threadId":"29973","inReplyTo":"7vy5qv70mh.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2012-03-20T18:31:19Z","receivedAt":"2012-03-20T18:31:19Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Tue, Mar 20, 2012 at 11:28 AM, Junio C Hamano wrote:\n> As many people already said in the discussion before the RFD message that\n> is at the root of this thread, the name of the option --force alone\n> already signals it is something you use after thinking twice.\n\nDefinitely. You may think twice about the branch you' re planning to\nforce-update. \"Do I really want to force-update ?\". But it\ndoesn't mean you know and fully understand the \"push default\" rules of\ngit.\n\nWith \"immediately\" I mean \"sooner than several releases away\".\n\nIn any case, seems I missed the train and the discussion is closed;\nI'll head back to my cave.\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- Software Architect - OLPC\n - ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"187360","messageId":"4F68F4A3.60506@pileofstuff.org","threadId":"29973","inReplyTo":"7vsjh48af1.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-03-20T21:20:35Z","receivedAt":"2012-03-20T21:20:35Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 19/03/12 22:59, Junio C Hamano wrote:\n> Andrew Sayers writes:\n> \n>> On 19/03/12 21:43, Junio C Hamano wrote:\n>>>\n>>> The same response applies. These administrators are taking responsibility\n>>> for their users by making them out of our reach.\n>>\n>> I'm not sure I follow. It sounds like you're saying we should avoid\n>> helping anyone that doesn't stick to our upgrade schedule,...\n> \n> I am not saying \"should avoid\". I am saying it is not much use.\n> \n> All we can do is to inform, educate and help those who are taking\n> responsibility, be it LTS distro or these administrators, to help their\n> users. I've already outlined what LTS distros could do with backporting\n> and reverting in the previous message.\n> \n> We can make sure that the \"default flip\" and \"stop warn\" patches can be\n> easily cherry-picked by them, even though we cannot force them to do so.\n\nSo we've identified the following groups:\n\n1. People who can't be harmed by this change (e.g. new users and people\nthat would only ever use the new default behaviour)\n\n2. People who are harmed by this change, and get information from this\nlist via some direct or indirect means (e.g. kernel devs or people using\na well-behaved distro)\n\n3. People who are harmed by this change, are impervious to information\nfrom this list, but update at sensible intervals and pay attention to\nwarning messages (e.g. corporate environments with frequent upgrade cycles)\n\n4. People who are harmed by this change, are impervious to information\nfrom this list, update at long intervals and pay attention to warning\nmessages (e.g. corporate environments with infrequent upgrade cycles)\n\n5. People who are harmed by this change, upgrade their system\noccasionally, but don't want to hear about behaviour changing from what\nit has always been (Slackware users ;)\n\nI guess we can agree that group 1 is already well cared for by recent\npublicity, and group 5 is beyond our ability to handle.\n\nEasy-to-cherry-pick patches are a good solution for group 2 - how about\nalso making a second \"default flip\" patch available earlier, for people\nthat want to go ahead of the main repo? For example, Debian might want\nto put this patch in before a feature freeze hits so that their build of\ngit behaves the same as everyone else once they've finished the\nextensive QA process for the distro.\n\nWarning messages as you've described them are a good solution for group\n3. I think we disagree about the size of this group, but I've only got\nanecdotal evidence so what do I know.\n\nPeople in group 4 aren't served well by any solution that involves some\nday removing the warning altogether, because there will always be\nsomeone that upgrades the day after we remove the warning and says \"why\nwasn't I informed?\".\n\nI assume the reason for removing the warning altogether is that some day\nthe signal:noise ratio will just get too bad. Improving the S:N ratio\nstrikes me as useful even ignoring group 4, but anything that increases\nthe amount of time we can warn means that more of them will be informed.\n\nThis might have been implicit all along, but one easy way to improve the\nS:N ratio would be to have the warning message tell people to use `git\nconfig --global`. Then people only ever need to see the message once\neach, no matter how many repos they create.\n\nWe could also try to measure the S:N ratio by having a period where the\nmessage says \"... please e-mail git@vger.kernel.org if you found this\nmessage useful, otherwise we'll assume nobody cares and delete it\".\nThen when somebody comes along and asks why they weren't informed, we at\nleast have a good answer.\n\nFinally, as a modification to my previous suggestion, we could `git\nconfig push.default ` when new repos are created and no\nglobal/system push.default is found, *instead* of removing the warning\naltogether at the end of the process. This would mean that everyone in\ngroup 3 is informed, as are the vast majority of group 4. The only\npeople that can then be harmed are those that do an exceptionally good\njob of disguising themselves as new users (e.g. scripts that regularly\ncreate throw-away repositories without ever looking at old ones).\n\n\t- Andrew\n"},{"id":"187367","messageId":"7vhaxi50q8.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"4F68F4A3.60506@pileofstuff.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-20T23:09:03Z","receivedAt":"2012-03-20T23:09:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Sayers writes:\n\n> I assume the reason for removing the warning altogether is that some day\n> the signal:noise ratio will just get too bad.\n\nThe reasoning is a lot simpler than that.\n\nIf the end game is not remove the warning, then we would be switching to a\nnew default that is \"give loud warning until the user configures her own\ndefault, but push upstream/current anyway\" mode. We do not want such a\nstupid mode as the default---we want the default to be either upstream or\ncurrent at the end, when nobody remembers what the ancient default was.\n\nThe \"warn loud but do it anyway\" is a very good interim step during the\nmigration, but is never a good default. If we are going to stop there,\n\"give loud warning until the user chooses and configures the default, and\npush nothing\" mode would be a LOT safer and saner default, as it would\nreally force people to configure the default. Obviously we do not want to\ngo there, so...\n"},{"id":"187370","messageId":"4F6915A8.9040009@pileofstuff.org","threadId":"29973","inReplyTo":"7vhaxi50q8.fsf@alter.siamese.dyndns.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-03-20T23:41:28Z","receivedAt":"2012-03-20T23:41:28Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 20/03/12 23:09, Junio C Hamano wrote:\n> Andrew Sayers writes:\n> \n>> I assume the reason for removing the warning altogether is that some day\n>> the signal:noise ratio will just get too bad.\n> \n> The reasoning is a lot simpler than that.\n> \n> If the end game is not remove the warning, then we would be switching to a\n> new default that is \"give loud warning until the user configures her own\n> default, but push upstream/current anyway\" mode. We do not want such a\n> stupid mode as the default---we want the default to be either upstream or\n> current at the end, when nobody remembers what the ancient default was.\n> \n> The \"warn loud but do it anyway\" is a very good interim step during the\n> migration, but is never a good default. If we are going to stop there,\n> \"give loud warning until the user chooses and configures the default, and\n> push nothing\" mode would be a LOT safer and saner default, as it would\n> really force people to configure the default. Obviously we do not want to\n> go there, so...\n> \n\nIt sounds like we're disagreeing, but I can't tell what about. I agree\nthat \"warn loud but do it anyway\" is a bad default in the long term. I\npropose implementing the behaviour you want by adding a push.default\nsetting to the .git/config file for all new repositories, so that users\nwith a longer-than-expected short term still get the warning. That\nshould warn 99% of the people who need it without bothering anyone that\ndoesn't. What am I missing?\n\n\t- Andrew\n"},{"id":"187373","messageId":"7vwr6e3ilx.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"4F6915A8.9040009@pileofstuff.org","subject":"Re: Please discuss: what \"git push\" should do when you do not say what to push?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-21T00:25:46Z","receivedAt":"2012-03-21T00:25:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Sayers writes:\n\n> It sounds like we're disagreeing, but I can't tell what about.\n\nYou are trying to read me too deeply, when there is nothing that deep to\nread, by for example assuming the s/n ratio is why we want to keep the\nwarning only for a while and then eventually removing.\n"},{"id":"187409","messageId":"7vr4wl262q.fsf@alter.siamese.dyndns.org","threadId":"29973","inReplyTo":"7vty1ndcoi.fsf@alter.siamese.dyndns.org","subject":"Summary of discussion on \"git push\" default change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-21T17:54:05Z","receivedAt":"2012-03-21T17:54:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"By now it should be obvious that most people would prefer to see the\ndefault behaviour for 'git push' to be something other than matching, even\nif you did not read each and every \"me too\" message.\n\nActually, we've known it from the beginning. Otherwise, we wouldn't have\nmade noises about it in the first place ;-). It was not the primary\nobjective of the discussion thread to decide if we are going to switch\naway from 'matching' by voting (waking up those who are sleeping, so that\nthey do not have to be surprised with \"I didn't know that was happening!\"\nwas).\n\nThe new default we are switching to is not about how many people prefer it\nfor their own use. It is about what default is the least confusing to the\nnew users. A default whose behaviour is easy to explain, easy to follow\nand easy to understand is the goal. Once people understand what they want\nand realize they fall into a minority, it is easy for them to configure\ntheir push.default to something else, like 'matching'. And 'matching' was\na bad default for that purpose; it was the hardest to explain and\nunderstand in the context of the workflows of many new people.\n\nMany people said that they like 'upstream' solely based on their personal\npreference, but a few people did justify their preference of 'upstream'\nover 'current' based on their experience in teaching new people and\nobserving the sharp edges that hurt them. And they all sounded reasonable.\n\nIn order to show how the world after phase #2 of the transition [*1*]\nwould look like to developers, testers and early adopters, I am planning\nmerge Matthieu's patch mm/push-default-switch-warning topic [*2*] to\n'next', together with Christopher's ct/advise-push-default topic [*3*];\nhopefully these topics can be merged to 'master' soon after 1.7.10 final.\n\nThanks.\n\nTo people who helped spreading the initial RFD message: please do feel\nfree to distribute this message to the same channels, too.\n\n\n[References]\n\n*1* http://article.gmane.org/gmane.comp.version-control.git/193308\n\n*2* https://github.com/gitster/git/commit/5293b54\n\n*3* https://github.com/gitster/git/commit/f25950f\n"},{"id":"187411","messageId":"vpqlimtj0dt.fsf@bauges.imag.fr","threadId":"29973","inReplyTo":"7vr4wl262q.fsf@alter.siamese.dyndns.org","subject":"Re: Summary of discussion on \"git push\" default change","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-21T18:05:02Z","receivedAt":"2012-03-21T18: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> In order to show how the world after phase #2 of the transition [*1*]\n> would look like to developers, testers and early adopters, I am planning\n> merge Matthieu's patch mm/push-default-switch-warning topic [*2*]\n\nGreat. There was a few nitpick about my version (s/1.8/2.0/, static\nvariable), but I can see that you have already fixed them.\n\nIt may make sense to create a branch like v2.0 in git.git to start\ncollecting \"switch default\" kind of patches, to be merged before 2.0 is\nreleased. There were other points in the \"1.8.0\" discussion that may\nstill be valid (I'm not sure what the status of \"make add -u full tree\"\nis for example):\n\n http://permalink.gmane.org/gmane.comp.version-control.git/167149\n\n(BTW, does your cristal ball say anything about the release date of\n2.0?)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"}]}