{"thread":{"id":"18009","subject":"git push","startedAt":"2009-02-25T06:38:41Z","lastAt":"2009-03-05T09:44:10Z","messageCount":17,"participants":["John Tapsell","Jeff King","Junio C Hamano","Jay Soffian","Finn Arne Gangstad","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106138","messageId":"43d8ce650902242238s7ab4c851p9c820c96b67aa62b@mail.gmail.com","threadId":"18009","inReplyTo":null,"subject":"git push","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-02-25T06:38:41Z","receivedAt":"2009-02-25T06:38:41Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"Hi all,\n\n Following the idea of 'least damage', what do people think of making\n\"git push\" only push the branch you are currently on?\n\n I've accidentally committed commits in other branches because of a\ngit push. I know there's some magic config kung-foo that you can do\nto try to tame git push to just the current branch, but it would make\nsense to have this as default.\n\nJohn\n"},{"id":"106140","messageId":"20090225064659.GA1506@sigill.intra.peff.net","threadId":"18009","inReplyTo":"43d8ce650902242238s7ab4c851p9c820c96b67aa62b@mail.gmail.com","subject":"Re: git push","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-25T06:46:59Z","receivedAt":"2009-02-25T06:46:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 25, 2009 at 06:38:41AM +0000, John Tapsell wrote:\n\n> Following the idea of 'least damage', what do people think of making\n> \"git push\" only push the branch you are currently on?\n\nI think it has been discussed several times in the past. I think the\nmost recent was last October. So you might try searching the list\narchives around that time.\n\n-Peff\n"},{"id":"106142","messageId":"7vskm3c84t.fsf@gitster.siamese.dyndns.org","threadId":"18009","inReplyTo":"43d8ce650902242238s7ab4c851p9c820c96b67aa62b@mail.gmail.com","subject":"Re: git push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-25T07:01:38Z","receivedAt":"2009-02-25T07:01:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Tapsell writes:\n\n> Following the idea of 'least damage', what do people think of making\n> \"git push\" only push the branch you are currently on?\n\nHaving an easy way to ask to push only one branch (typically the currently\nchecked-out one) is a good thing. You can obviously say \"git push origin\nmaster\" (or whatever branch you are on). We also added \"git push origin\nHEAD\". I thought we even added \"git push HEAD\" or \"git push --current\",\nbut I may be mistaken.\n\nBut if you are talking about changing the default when \"git push\" is run\nwithout any parameter, I have to say it is a terrible idea, for two\nreasons, and one is too obvious to state so I wouldn't repeat it and talk\nonly about the other one.\n\nI've noticed that people who ask for such a default tend to push too often\nand worse they tend to push before they have their act together. Surely\ntheir other branches may not be ready, but it is likely their current\nbranch isn't either ;-)\n\nIf you shoot for the least damage for such people, the sanest default for\n\"git push\" would be to do nothing. You *always* say what to push where,\nthen there is no risk of pushing something you did not intend to. Perhaps\n\"push.default = never\" configuration may not be such a bad idea?\n"},{"id":"106143","messageId":"43d8ce650902242309nef12bd9j9088170b18cc8d4e@mail.gmail.com","threadId":"18009","inReplyTo":"7vskm3c84t.fsf@gitster.siamese.dyndns.org","subject":"Re: git push","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-02-25T07:09:42Z","receivedAt":"2009-02-25T07:09:42Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/2/25 Junio C Hamano :\n> John Tapsell writes:\n>\n>>   Following the idea of 'least damage', what do people think of making\n>> \"git push\" only push the branch you are currently on?\n>\n> Having an easy way to ask to push only one branch (typically the currently\n> checked-out one) is a good thing.  You can obviously say \"git push origin\n> master\" (or whatever branch you are on).  We also added \"git push origin\n> HEAD\".  I thought we even added \"git push HEAD\" or \"git push --current\",\n> but I may be mistaken.\n>\n> But if you are talking about changing the default when \"git push\" is run\n> without any parameter, I have to say it is a terrible idea, for two\n> reasons, and one is too obvious to state so I wouldn't repeat it and talk\n> only about the other one.\n\nPresumably the obvious is that it might be confusing to existing\nusers? Perhaps, but it doesn't cause any damage. It's moving to a\n'safer' default.\n\n> I've noticed that people who ask for such a default tend to push too often\n> and worse they tend to push before they have their act together.  Surely\n> their other branches may not be ready, but it is likely their current\n> branch isn't either ;-)\n\nYou're against making push affect only the current branch in order to\npunish people who push too often? Okaaay..\n\n> If you shoot for the least damage for such people, the sanest default for\n> \"git push\" would be to do nothing.  You *always* say what to push where,\n> then there is no risk of pushing something you did not intend to.  Perhaps\n> \"push.default = never\" configuration may not be such a bad idea?\n\nThat wouldn't be a terrible idea, although perhaps a bit strange.\n\nJohn\n"},{"id":"106146","messageId":"7v4oyjc64z.fsf@gitster.siamese.dyndns.org","threadId":"18009","inReplyTo":"43d8ce650902242309nef12bd9j9088170b18cc8d4e@mail.gmail.com","subject":"Re: git push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-25T07:44:44Z","receivedAt":"2009-02-25T07:44:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Tapsell writes:\n\n> 2009/2/25 Junio C Hamano :\n>\n>> Having an easy way to ask to push only one branch (typically the currently\n>> checked-out one) is a good thing.  You can obviously say \"git push origin\n>> master\" (or whatever branch you are on).  We also added \"git push origin\n>> HEAD\".  I thought we even added \"git push HEAD\" or \"git push --current\",\n>> but I may be mistaken.\n>>\n>> But if you are talking about changing the default when \"git push\" is run\n>> without any parameter, I have to say it is a terrible idea, for two\n>> reasons, and one is too obvious to state so I wouldn't repeat it and talk\n>> only about the other one.\n>\n> Presumably the obvious is that it might be confusing to existing\n> users? Perhaps, but it doesn't cause any damage. It's moving to a\n> 'safer' default.\n\nNo, it is not merely confusing but is outright dangerous to people who\nexpect the \"matching refs\" behaviour. It is not safer at all.\n\nFor example, I almost always have some topic branch checked out and\nworking on changes that are still not in any of my integration branches.\nThe workflow is to first finish topics to satisfaction, merge the ones\nthat are ready into their respective integration branches, and in other\nwork trees (created by contrib/workdir/git-new-workdir) run the whole\nbuild and test cycle for them in the background. While waiting for them\nto build and verified, the repository I primarily work in will have a\ncheckout of some other uncooked topic branch that I have no intention to\npush out yet because I am still working on it. After a while, the\nbackground build and test will complete and all integration branches prove\nthemselves to be ready to be pushed out, and I can say \"git push\", fully\nexpecting that the \"matching refs\" behaviour will push out the integration\nbranches and nothing else, because they are the only ones I have on the\npublic side for people (either git or day-job) to look at. I would never\nwant \"push current branch\" to send the uncooked topic branch, which I\nwould never want to have on the other side even if it is fully cooked.\n\nEven when I am on 'master', when I push things out, I do not want to hear\nfrom people that I have been forgetting to push out integration branches\nother than 'master' only because you suddenly changed the default under\nme after a few days.\n\nPlease don't talk about changing the default without thinking the\nramifications through.\n\n>> I've noticed that people who ask for such a default tend to push too often\n>> and worse they tend to push before they have their act together.  Surely\n>> their other branches may not be ready, but it is likely their current\n>> branch isn't either ;-)\n>\n> You're against making push affect only the current branch in order to\n> punish people who push too often? Okaaay..\n\n\"Too often\" is not a problem by itself per-se, but \"still broken\"\ncertainly is, and \"not thought through\" also is to a certain degree. You\noften see people commit and push out an early part of a series, and then\nlater regret that they realize the approach in these initial segment does\nnot pan out and another avenue was much better, but it is too late to take\nthem back and rebase.\n\nAnd there unfortunately is a correlation between \"too often\" and the other\ntwo. Not very strong correlation with \"still broken\", but moderately\nstrong correlation with \"not thought through\".\n\nAnd this is not about punishing. It is about getting into a different\nmindset. Unlike CVS/SVN, committing and publishing can be made into\ndifferent phases with git, and not pushing too early allows you produce a\nlot better results. \"I want to push only this branch\" is often (not\nalways, but \"often\" stands with strong correlation) a sign that other\nthings are not ready, and by definition you couldn't have thought through\ninteractions between what you _think_ is ready (i.e. the current branch)\nand the other ones that are not ready. In other words, it is about\nencouraging people to think things through before publishing.\n\n>> If you shoot for the least damage for such people, the sanest default for\n>> \"git push\" would be to do nothing.  You *always* say what to push where,\n>> then there is no risk of pushing something you did not intend to.  Perhaps\n>> \"push.default = never\" configuration may not be such a bad idea?\n>\n> That wouldn't be a terrible idea, although perhaps a bit strange.\n\nI would say that is the sanest default, and I often wish people in the git\ntraining industry never teach \"git push\" without $remote and $refs\nparameter to new people until they understand what they are doing.\n\nYou can add words other than 'never' to the repertoire, such as 'current',\nor 'matching'. I think the configuration actually should be\n\"remote..push\", not \"push.default\", though.\n\nOh, and the value 'current' can be spelled as 'HEAD' already there.\n"},{"id":"106178","messageId":"20090225090230.GA15919@coredump.intra.peff.net","threadId":"18009","inReplyTo":"7v4oyjc64z.fsf@gitster.siamese.dyndns.org","subject":"Re: git push","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-25T09:02:31Z","receivedAt":"2009-02-25T09:02:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 24, 2009 at 11:44:44PM -0800, Junio C Hamano wrote:\n\n> > Presumably the obvious is that it might be confusing to existing\n> > users? Perhaps, but it doesn't cause any damage. It's moving to a\n> > 'safer' default.\n> \n> No, it is not merely confusing but is outright dangerous to people who\n> expect the \"matching refs\" behaviour. It is not safer at all.\n\nI think this is a very good reason not to change the default \"push\"\nbehavior.\n\n> And this is not about punishing. It is about getting into a different\n> mindset. Unlike CVS/SVN, committing and publishing can be made into\n> different phases with git, and not pushing too early allows you produce a\n> lot better results. \"I want to push only this branch\" is often (not\n> always, but \"often\" stands with strong correlation) a sign that other\n> things are not ready, and by definition you couldn't have thought through\n> interactions between what you _think_ is ready (i.e. the current branch)\n> and the other ones that are not ready. In other words, it is about\n> encouraging people to think things through before publishing.\n\nBut I don't buy this at all. It is totally dependent on workflow and how\nyou use branches. That is, the \"readiness\" of two branches may be\ntotally unrelated. One may be a short-term branch for today's work, and\nthe other may be a long-running branch that you have made a WIP commit\non. You may even have that WIP commit sitting there for days.\n\nWhen you think about \"is my current branch ready to push?\" there is no\nreason for you to think of that other long-running branch that you\nhaven't seen for days.\n\n-Peff\n"},{"id":"106180","messageId":"43d8ce650902250108q48837d85mfcee33b990c5bf00@mail.gmail.com","threadId":"18009","inReplyTo":"7v4oyjc64z.fsf@gitster.siamese.dyndns.org","subject":"Re: git push","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-02-25T09:08:36Z","receivedAt":"2009-02-25T09:08:36Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/2/25 Junio C Hamano :\n> John Tapsell writes:\n>\n>> 2009/2/25 Junio C Hamano :\n>>\n>>> Having an easy way to ask to push only one branch (typically the currently\n>>> checked-out one) is a good thing.  You can obviously say \"git push origin\n>>> master\" (or whatever branch you are on).  We also added \"git push origin\n>>> HEAD\".  I thought we even added \"git push HEAD\" or \"git push --current\",\n>>> but I may be mistaken.\n>>>\n>>> But if you are talking about changing the default when \"git push\" is run\n>>> without any parameter, I have to say it is a terrible idea, for two\n>>> reasons, and one is too obvious to state so I wouldn't repeat it and talk\n>>> only about the other one.\n>>\n>> Presumably the obvious is that it might be confusing to existing\n>> users?  Perhaps, but it doesn't cause any damage.  It's moving to a\n>> 'safer' default.\n>\n> No, it is not merely confusing but is outright dangerous to people who\n> expect the \"matching refs\" behaviour.  It is not safer at all.\n\nI see your point - perhaps \"git push\" should push the current branch\nif the branch name matches the remote name (so if the current 'git\npush' would have pushed it). Otherwise tell the user how to force it\nto push.\n\n> Please don't talk about changing the default without thinking the\n> ramifications through.\n\nTalking about doesn't harm anything. I don't really get why you're a\nbit hostile.\n\n\n>>> I've noticed that people who ask for such a default tend to push too often\n>>> and worse they tend to push before they have their act together.  Surely\n>>> their other branches may not be ready, but it is likely their current\n>>> branch isn't either ;-)\n>>\n>> You're against making push affect only the current branch in order to\n>> punish people who push too often?  Okaaay..\n>\n> \"Too often\" is not a problem by itself per-se, but \"still broken\"\n> certainly is, and \"not thought through\" also is to a certain degree.  You\n> often see people commit and push out an early part of a series, and then\n> later regret that they realize the approach in these initial segment does\n> not pan out and another avenue was much better, but it is too late to take\n> them back and rebase.\n>\n> And there unfortunately is a correlation between \"too often\" and the other\n> two.  Not very strong correlation with \"still broken\", but moderately\n> strong correlation with \"not thought through\".\n>\n> And this is not about punishing.  It is about getting into a different\n> mindset.  Unlike CVS/SVN, committing and publishing can be made into\n> different phases with git, and not pushing too early allows you produce a\n> lot better results.  \"I want to push only this branch\" is often (not\n> always, but \"often\" stands with strong correlation) a sign that other\n> things are not ready, and by definition you couldn't have thought through\n> interactions between what you _think_ is ready (i.e. the current branch)\n> and the other ones that are not ready.  In other words, it is about\n> encouraging people to think things through before publishing.\n\nI'm a bit surprised that you always push all your branches at once. I\noften have several branches checked out at different stages of\ndevelopment. Perhaps working on a branch, then I find a serious bug,\nso I switch to master and fix the bug there. I have never wanted to\npush multiple branches at once.\n\n>>> If you shoot for the least damage for such people, the sanest default for\n>>> \"git push\" would be to do nothing.  You *always* say what to push where,\n>>> then there is no risk of pushing something you did not intend to.  Perhaps\n>>> \"push.default = never\" configuration may not be such a bad idea?\n>>\n>> That wouldn't be a terrible idea, although perhaps a bit strange.\n>\n> I would say that is the sanest default, and I often wish people in the git\n> training industry never teach \"git push\" without $remote and $refs\n> parameter to new people until they understand what they are doing.\n>\n> You can add words other than 'never' to the repertoire, such as 'current',\n> or 'matching'.  I think the configuration actually should be\n> \"remote..push\", not \"push.default\", though.\n>\n> Oh, and the value 'current' can be spelled as 'HEAD' already there.\n"},{"id":"106182","messageId":"7viqmy7tqk.fsf@gitster.siamese.dyndns.org","threadId":"18009","inReplyTo":"20090225090230.GA15919@coredump.intra.peff.net","subject":"Re: git push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-25T09:26:11Z","receivedAt":"2009-02-25T09:26:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> But I don't buy this at all. It is totally dependent on workflow and how\n> you use branches.\n\nOf course. \"Encouraging a behaviour\" means just that. A better workflow\nand a better use of branches.\n\n> When you think about \"is my current branch ready to push?\" there is no\n> reason for you to think of that other long-running branch that you\n> haven't seen for days.\n\nSorry, I have to disagree with that.\n\nWe are talking about people to whom the \"push matching refs\" is a problem,\nand that means they are using a branch with the same name with other\npeople (either from a shared central repository or his own publishing\nbranch) to house long-running, intermediate, uncooked state.\n\nWhy aren't you forking off your own topic branch from such a branch that\nis either shared (or for publishing)? For the purpose of this discussion,\nshared branch is the same as your own publishing branch -- that's where\nyou put things that are *ready* to be seen by other people.\n\nThe one you haven't seen for days, if it is not shared, won't bother you\nnor your \"matching push\", because you wouldn't have merged your uncooked\nchanges from your own topic branch to that shared branch yet.\n"},{"id":"106184","messageId":"76718490902250134q580caaffuf5f13d87e3d0974c@mail.gmail.com","threadId":"18009","inReplyTo":"7v4oyjc64z.fsf@gitster.siamese.dyndns.org","subject":"Re: git push","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-25T09:34:54Z","receivedAt":"2009-02-25T09:34:54Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Wed, Feb 25, 2009 at 2:44 AM, Junio C Hamano wrote:\n\n> Oh, and the value 'current' can be spelled as 'HEAD' already there.\n\nJohn - in case you missed this, the behavior you desire is already available:\n\n(next)$ git config remote.origin.push HEAD\n(next)$ git remote show origin\n [...]\n Local ref configured for 'git push':\n HEAD pushes to next (fast forwardable)\n(next)$ git checkout master\n\n(master)$ git remote show origin\n [...]\n Local ref configured for 'git push':\n HEAD pushes to master (fast forwardable)\n\nj.\n"},{"id":"106186","messageId":"7v4oyi7sn4.fsf@gitster.siamese.dyndns.org","threadId":"18009","inReplyTo":"43d8ce650902250108q48837d85mfcee33b990c5bf00@mail.gmail.com","subject":"Re: git push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-25T09:49:51Z","receivedAt":"2009-02-25T09:49:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Tapsell writes:\n\n> 2009/2/25 Junio C Hamano :\n>\n>> Please don't talk about changing the default without thinking the\n>> ramifications through.\n>\n> Talking about doesn't harm anything. I don't really get why you're a\n> bit hostile.\n\nI am not saying any discussion about the defaults is bad.\n\nBut these topics add flames from uninformed people we have to douse early\nto the list traffic, and make it harder to find useful topics by degrading\nS/N ratio.\n\nIn other words, it certainly harms a lot.\n\nI just want people to think twice (or more) if the change you are going to\npropose is worthwhile before imposing that cost to everybody. A couple of\nchanges around \"git push\" scheduled for 1.7.0 are default changes, and it\nwas worthwhile to discuss about them, but I do not think this one deserves\nthe human bandwidth, especially we already had discussion on it recently\nand we have a reasonable configuration mechanism for doing what you want\nalready.\n"},{"id":"106187","messageId":"7vzlga6dzy.fsf@gitster.siamese.dyndns.org","threadId":"18009","inReplyTo":"76718490902250134q580caaffuf5f13d87e3d0974c@mail.gmail.com","subject":"Re: git push","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-25T09:51:29Z","receivedAt":"2009-02-25T09:51:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n> On Wed, Feb 25, 2009 at 2:44 AM, Junio C Hamano wrote:\n>\n>> Oh, and the value 'current' can be spelled as 'HEAD' already there.\n>\n> John - in case you missed this, the behavior you desire is already available:\n>\n> (next)$ git config remote.origin.push HEAD\n> (next)$ git remote show origin\n> [...]\n> Local ref configured for 'git push':\n> HEAD pushes to next (fast forwardable)\n> (next)$ git checkout master\n>\n> (master)$ git remote show origin\n> [...]\n> Local ref configured for 'git push':\n> HEAD pushes to master (fast forwardable)\n\nThanks.\n"},{"id":"106188","messageId":"20090225095129.GA16357@coredump.intra.peff.net","threadId":"18009","inReplyTo":"7viqmy7tqk.fsf@gitster.siamese.dyndns.org","subject":"Re: git push","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-25T09:51:30Z","receivedAt":"2009-02-25T09:51:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 25, 2009 at 01:26:11AM -0800, Junio C Hamano wrote:\n\n> Of course. \"Encouraging a behaviour\" means just that. A better workflow\n> and a better use of branches.\n\nI don't agree that it is necessarily a better workflow.\n\n> > When you think about \"is my current branch ready to push?\" there is no\n> > reason for you to think of that other long-running branch that you\n> > haven't seen for days.\n> \n> Sorry, I have to disagree with that.\n> \n> We are talking about people to whom the \"push matching refs\" is a problem,\n> and that means they are using a branch with the same name with other\n> people (either from a shared central repository or his own publishing\n> branch) to house long-running, intermediate, uncooked state.\n\nI do this all the time by making \"wip\" commits on top of my topic\nbranches. I push the topic branches to a networked repo so they are\naccessible and backed up. Then when I work, I do something like:\n\n (1) git checkout jk/existing-topic\n (2) hack hack hack\n (3) # oops, must sleep on this topic\n (4) git commit -a -m wip\n (5) sleep sleep sleep\n (6) # oops, I need to work on something else this morning\n (6) git checkout -b jk/new-topic master\n (7) # ok, master is ready\n (8) git push origin HEAD\n\nI don't want my WIP commit pushed; it is a purely local and temporary\nplaceholder.\n\nIt seems that you are suggesting that I should never put such uncooked\nstate onto a branch that has already been pushed. Which means I should\nreplace (4) with \"git checkout -b jk/topic-subtopic\". This is a pain.\nWhen I come back to the topic, I want to:\n\n git checkout jk/existing-topic\n gitk origin.. ;# where was I? Oh right, a WIP.\n\nI think where I am leaving your mental model is that my published\nbranches are not necessarily \"long running\" in the same way that you\nthink. I publish them so I can pick them up elsewhere, and maybe even so\nother people can see what I'm working on. But they really are topic\nbranches.\n\n-Peff\n"},{"id":"106198","messageId":"43d8ce650902250206j7f8411a4p5d256e0a4da7fe49@mail.gmail.com","threadId":"18009","inReplyTo":"7v4oyi7sn4.fsf@gitster.siamese.dyndns.org","subject":"Re: git push","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-02-25T10:06:03Z","receivedAt":"2009-02-25T10:06:03Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/2/25 Junio C Hamano :\n> John Tapsell writes:\n>\n>> 2009/2/25 Junio C Hamano :\n>>\n>>> Please don't talk about changing the default without thinking the\n>>> ramifications through.\n>>\n>> Talking about doesn't harm anything.  I don't really get why you're a\n>> bit hostile.\n>\n> I am not saying any discussion about the defaults is bad.\n>\n> But these topics add flames from uninformed people we have to douse early\n> to the list traffic, and make it harder to find useful topics by degrading\n> S/N ratio.\n\nYou know, there might be a reason why you get lots of \"uninformed\npeople\" complaining about the defaults. Distinguishing the flames\nshouldn't be your first instinct :)\n\n> In other words, it certainly harms a lot.\n>\n> I just want people to think twice (or more) if the change you are going to\n> propose is worthwhile before imposing that cost to everybody.  A couple of\n> changes around \"git push\" scheduled for 1.7.0 are default changes, and it\n> was worthwhile to discuss about them, but I do not think this one deserves\n> the human bandwidth, especially we already had discussion on it recently\n> and we have a reasonable configuration mechanism for doing what you want\n> already.\n"},{"id":"106272","messageId":"20090225225826.GA13510@pvv.org","threadId":"18009","inReplyTo":"7vskm3c84t.fsf@gitster.siamese.dyndns.org","subject":"Re: git push","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-02-25T22:58:26Z","receivedAt":"2009-02-25T22:58:26Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"Sorry to people receiving this mail twice, the list ate my first reply\nsince it managed to hit the spam-filter (maybe I should take a hint... :)\n\nOn Tue, Feb 24, 2009 at 11:01:38PM -0800, Junio C Hamano wrote:\n> [...]\n>\n> But if you are talking about changing the default when \"git push\" is run\n> without any parameter, I have to say it is a terrible idea, for two\n> reasons, and one is too obvious to state so I wouldn't repeat it and talk\n> only about the other one.\n\nThe current default behaviour of git push is very annoying for us at\nleast. The current behaviour is _dangerous_ and leads to serious\nproblems. It is too easy for someone to write \"git push\". They hit\nenter too soon, or they write it expecting to get usage\ninformation. They do not necessarily expect to overwrite random\nbranches in a remote repository.\n\nMost git commands are not destructive with no arguments at all, and\npush is the _only_ command that really can screw things up for others,\nso this command in particular should refrain from destructive default\nbehaviour.\n\nAn example of random branch overwriting:\n$ mkdir a\n$ cd a\n$ git init\n$ echo contents > file\n$ git add file\n$ git commit -m message\n$ cd ..\n$ git clone a b\n$ cd b\n$ git checkout -b gif-support\n$ echo foo > somefile\n$ git add somefile\n$ git commit -m message\n$ ( cd ../a && git branch gif-support) # Assume done by someone else\n$ git checkout master\n$ # \n$ git push # <-- OOOPS! pushes gif-support!\n\nNotice that what branches git push ends up pushing is out of your\ncontrol, since new branches can appear in the remote repository at any\ntime. This is very unfriendly in our setup with a shared incoming repo.\n\nIf developer A creates \"gif-support\", shares it with developer B, who\ndoes an additional commit on it to make it print more debug info (but\nhas no intent of pushing it anywhere), and A pushes it to the \"incoming\"\nrepo, developer B risks overwriting that with his debug version.\n\nIt is not realistic to believe that in a big project with many\ndevelopers, no one will ever do the mistake of typing \"git push\". It\nis also not realistic to believe that everyone will know how to (or\nremember to) configure this away.\n\n> If you shoot for the least damage for such people, the sanest default for\n> \"git push\" would be to do nothing. You *always* say what to push where,\n> then there is no risk of pushing something you did not intend to. Perhaps\n> \"push.default = never\" configuration may not be such a bad idea?\n\nIf \"git push\" could do nothing at all without configuring anything, that\nwould be a big improvement to us.\n\n- Finn Arne\n"},{"id":"107034","messageId":"49AF9117.1020407@op5.se","threadId":"18009","inReplyTo":"20090225225826.GA13510@pvv.org","subject":"Re: git push","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-03-05T08:45:11Z","receivedAt":"2009-03-05T08:45:11Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Finn Arne Gangstad wrote:\n> Sorry to people receiving this mail twice, the list ate my first reply\n> since it managed to hit the spam-filter (maybe I should take a hint... :)\n> \n> On Tue, Feb 24, 2009 at 11:01:38PM -0800, Junio C Hamano wrote:\n>> [...]\n>>\n>> But if you are talking about changing the default when \"git push\" is run\n>> without any parameter, I have to say it is a terrible idea, for two\n>> reasons, and one is too obvious to state so I wouldn't repeat it and talk\n>> only about the other one.\n> \n> The current default behaviour of git push is very annoying for us at\n> least. The current behaviour is _dangerous_ and leads to serious\n> problems. It is too easy for someone to write \"git push\". They hit\n> enter too soon, or they write it expecting to get usage\n> information. They do not necessarily expect to overwrite random\n> branches in a remote repository.\n> \n> Most git commands are not destructive with no arguments at all, and\n> push is the _only_ command that really can screw things up for others,\n> so this command in particular should refrain from destructive default\n> behaviour.\n> \n> An example of random branch overwriting:\n> $ mkdir a\n> $ cd a\n> $ git init\n> $ echo contents > file\n> $ git add file\n> $ git commit -m message\n> $ cd ..\n> $ git clone a b\n> $ cd b\n> $ git checkout -b gif-support\n> $ echo foo > somefile\n> $ git add somefile\n> $ git commit -m message\n> $ ( cd ../a && git branch gif-support) # Assume done by someone else\n> $ git checkout master\n> $ # \n> $ git push # <-- OOOPS! pushes gif-support!\n> \n> Notice that what branches git push ends up pushing is out of your\n> control, since new branches can appear in the remote repository at any\n> time. This is very unfriendly in our setup with a shared incoming repo.\n> \n> If developer A creates \"gif-support\", shares it with developer B, who\n> does an additional commit on it to make it print more debug info (but\n> has no intent of pushing it anywhere), and A pushes it to the \"incoming\"\n> repo, developer B risks overwriting that with his debug version.\n> \n\ngit push will never overwrite changes in the remote repo unless you\nspecify --force. If anyone *blindly* uses --force, they really shouldn't\nhave write-access to anything so precious as your code repositories.\n\nWorst-case scenario, you commits that were never intended for publication\nenter your public wateringhole and needs a revert later on. Big deal.\n\n> It is not realistic to believe that in a big project with many\n> developers, no one will ever do the mistake of typing \"git push\". It\n> is also not realistic to believe that everyone will know how to (or\n> remember to) configure this away.\n> \n\nBut it *is* realistic to not assume that they will also use --force\nwhile doing so.\n\n>> If you shoot for the least damage for such people, the sanest default for\n>> \"git push\" would be to do nothing. You *always* say what to push where,\n>> then there is no risk of pushing something you did not intend to. Perhaps\n>> \"push.default = never\" configuration may not be such a bad idea?\n> \n> If \"git push\" could do nothing at all without configuring anything, that\n> would be a big improvement to us.\n> \n\nI can buy this, I guess. I always type the remote-name I want to push to\nanyways. A sane no-op default would probably be to list the pre-configured\nremotes along with a short usage message. I still don't quite see the point\nof it.\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":"107032","messageId":"43d8ce650903050056v4b7a22cfve2eb4d8d76717285@mail.gmail.com","threadId":"18009","inReplyTo":"49AF9117.1020407@op5.se","subject":"Re: git push","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-03-05T08:56:43Z","receivedAt":"2009-03-05T08:56:43Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/3/5 Andreas Ericsson :\n> Finn Arne Gangstad wrote:\n>>\n>> Sorry to people receiving this mail twice, the list ate my first reply\n>> since it managed to hit the spam-filter (maybe I should take a hint... :)\n>>\n>> On Tue, Feb 24, 2009 at 11:01:38PM -0800, Junio C Hamano wrote:\n>>>\n>>> [...]\n>>>\n>>> But if you are talking about changing the default when \"git push\" is run\n>>> without any parameter, I have to say it is a terrible idea, for two\n>>> reasons, and one is too obvious to state so I wouldn't repeat it and talk\n>>> only about the other one.\n>>\n>> The current default behaviour of git push is very annoying for us at\n>> least. The current behaviour is _dangerous_ and leads to serious\n>> problems. It is too easy for someone to write \"git push\". They hit\n>> enter too soon, or they write it expecting to get usage\n>> information. They do not necessarily expect to overwrite random\n>> branches in a remote repository.\n>>\n>> Most git commands are not destructive with no arguments at all, and\n>> push is the _only_ command that really can screw things up for others,\n>> so this command in particular should refrain from destructive default\n>> behaviour.\n>>\n>> An example of random branch overwriting:\n>> $ mkdir a\n>> $ cd a\n>> $ git init\n>> $ echo contents > file\n>> $ git add file\n>> $ git commit -m message\n>> $ cd ..\n>> $ git clone a b\n>> $ cd b\n>> $ git checkout -b gif-support\n>> $ echo foo > somefile\n>> $ git add somefile\n>> $ git commit -m message\n>> $ ( cd ../a && git branch gif-support) # Assume done by someone else\n>> $ git checkout master\n>> $ # \n>> $ git push  # <-- OOOPS! pushes gif-support!\n>>\n>> Notice that what branches git push ends up pushing is out of your\n>> control, since new branches can appear in the remote repository at any\n>> time. This is very unfriendly in our setup with a shared incoming repo.\n>>\n>> If developer A creates \"gif-support\", shares it with developer B, who\n>> does an additional commit on it to make it print more debug info (but\n>> has no intent of pushing it anywhere), and A pushes it to the \"incoming\"\n>> repo, developer B risks overwriting that with his debug version.\n>>\n>\n> git push will never overwrite changes in the remote repo unless you\n> specify --force. If anyone *blindly* uses --force, they really shouldn't\n> have write-access to anything so precious as your code repositories.\n\nIt's seems a very likely scenario to me.\n\nI work on a remote branch with one other person, to make some new\nfeature. Once we are done, I rebase and get rid of the cruft from the\nhistory, then \"git push --force\" to update the branch. Whoops, I've\njust unknowingly wiped out a completely different branch.\n\n>\n> Worst-case scenario, you commits that were never intended for publication\n> enter your public wateringhole and needs a revert later on. Big deal.\n>\n>> It is not realistic to believe that in a big project with many\n>> developers, no one will ever do the mistake of typing \"git push\".  It\n>> is also not realistic to believe that everyone will know how to (or\n>> remember to) configure this away.\n>>\n>\n> But it *is* realistic to not assume that they will also use --force\n> while doing so.\n>\n>>> If you shoot for the least damage for such people, the sanest default for\n>>> \"git push\" would be to do nothing.  You *always* say what to push where,\n>>> then there is no risk of pushing something you did not intend to.\n>>>  Perhaps\n>>> \"push.default = never\" configuration may not be such a bad idea?\n>>\n>> If \"git push\" could do nothing at all without configuring anything, that\n>> would be a big improvement to us.\n>>\n>\n> I can buy this, I guess. I always type the remote-name I want to push to\n> anyways. A sane no-op default would probably be to list the pre-configured\n> remotes along with a short usage message. I still don't quite see the point\n> of it.\n\nIf people don't agree on changing 'git push' to affect only the\ncurrent branch, I would also go for making 'git push' a noop.\n\nJohn\n\n>\n> --\n> Andreas Ericsson                   andreas.ericsson@op5.se\n> OP5 AB                             www.op5.se\n> Tel: +46 8-230225                  Fax: +46 8-230231\n>\n> Considering the successes of the wars on alcohol, poverty, drugs and\n> terror, I think we should give some serious thought to declaring war\n> on peace.\n>\n"},{"id":"107040","messageId":"20090305094410.GA26120@pvv.org","threadId":"18009","inReplyTo":"49AF9117.1020407@op5.se","subject":"Re: git push","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-03-05T09:44:10Z","receivedAt":"2009-03-05T09:44:10Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Thu, Mar 05, 2009 at 09:45:11AM +0100, Andreas Ericsson wrote:\n\n> Worst-case scenario, you commits that were never intended for publication\n> enter your public wateringhole and needs a revert later on. Big deal.\n\nIt could be a very big deal depending on what the contents are. I\nthink you can split developers in two groups - those who like to learn\na lot about version control systems, and those who just see it as a\nnecessary evil to get their job done. The latter seems to be the\nmajority.\n\nThe first group will know how to undo the damage from a bad push (and\nprobably configure their setup so they do not necessarily happen),\nwhile the second group will not necessarily notice that it happened or\nknow how to undo it. So, bad pushes go through, and are not detected\nbefore 3 other people base their work on it, and we get a lot of\nhassle.\n\n>> It is not realistic to believe that in a big project with many\n>> developers, no one will ever do the mistake of typing \"git push\". It\n>> is also not realistic to believe that everyone will know how to (or\n>> remember to) configure this away.\n>\n> But it *is* realistic to not assume that they will also use --force\n> while doing so.\n\nOur public repos are set up so that only a few chosen people are\nallowed to force pushes, so this is not an issue for us.\n\n>> If \"git push\" could do nothing at all without configuring anything, that\n>> would be a big improvement to us.\n>\n> I can buy this, I guess. I always type the remote-name I want to push to\n> anyways. A sane no-op default would probably be to list the pre-configured\n> remotes along with a short usage message. I still don't quite see the point\n> of it.\n\nI'll try to whip up a small patch series tonight and see what it ends\nup looking like.\n\n- Finn Arne\n"}]}