{"thread":{"id":"10047","subject":"git push (mis ?)behavior","startedAt":"2007-09-27T13:04:47Z","lastAt":"2007-10-09T07:23:42Z","messageCount":40,"participants":["Pierre Habouzit","Wincent Colaiuta","Benoit SIGOURE","Junio C Hamano","Steffen Prohaska","Johannes Schindelin","Miles Bader","Karl Hasselström","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"54165","messageId":"20070927130447.GH10289@artemis.corp","threadId":"10047","inReplyTo":null,"subject":"git push (mis ?)behavior","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-09-27T13:04:47Z","receivedAt":"2007-09-27T13:04:47Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":" There is a behavior of git-push that is the most annoying thing while\nworking with a central-repository: `git push` without any arguments\ninsists on pushing every local refspec that match one in origin.\n\n While it's perfectly correct when you push to a public repository (you\ndo that seldom, and usually only after having prepared it with care),\nit's not true for the central-repository layout. At work, I often have\nthis situation:\n\n [I'm in the devel branch, would be next for git e.g.]\n ... hack ... hack ... *OMG* what a nasty bug...\n $ git stash\n $ git checkout \n .. fix nasty bug ..\n $ git commit\n $ git push # so that co-workers have the fix asap\n $ git checkout \n $ git stash apply\n ... OOOOH NOES it pushed my WIP in my devel branch as well ...\n\n There has been (and still is atm) a quite heated discussion on IRC\nabout that. Some arguments were that pull/push were opposite words in\nEnglish, but weren't doing an opposite thing in git, which led to some\nfight. But that's not close to the point IMHO.\n\n The real question is \"what does users intend when they `git push`\". In\na git/kernel/... like model, you don't think the same than in a\nsvn/cvs-like model. I mean, Junio or Linus likely don't push a lot to\ntheir public repository. It happens probably a couple of time per day.\nWhile I'm at work, it happens up way more frequentely, and I then want\nto lazily type `git push` and not `git push origin `. it's\ntoo long.\n\n I'm not sure what we can do about it, but I'm pretty sure it bites a\nlot of people out there. For now I use this alias in my .gitconfig:\n\n p=!git-push origin `git-symbolic-ref HEAD`\n\nbut still, it feels really wrong to me. Not to mention that git-push(1)\nsays that it has a --all option that in fact is the current default\nbehavior, hence sounds pretty useless.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54166","messageId":"0CAD1C47-A396-46AA-9DC0-96BBD41EE4E4@wincent.com","threadId":"10047","inReplyTo":"20070927130447.GH10289@artemis.corp","subject":"Re: git push (mis ?)behavior","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-09-27T13:30:08Z","receivedAt":"2007-09-27T13:30:08Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 27/9/2007, a las 15:04, Pierre Habouzit escribió:\n\n> There is a behavior of git-push that is the most annoying thing \n> while\n> working with a central-repository: `git push` without any arguments\n> insists on pushing every local refspec that match one in origin.\n\nI kind of agree. Without reading the git-push man page I would \nintuitively expect \"git push\" with no arguments to push only the \nbranch I currently have checked out, and \"git push --all\" to push all.\n\n> I'm not sure what we can do about it, but I'm pretty sure it bites a\n> lot of people out there. For now I use this alias in my .gitconfig:\n>\n> p=!git-push origin `git-symbolic-ref HEAD`\n\nAh, nice alias! Thanks for sharing it.\n\nCheers,\nWincent\n"},{"id":"54172","messageId":"AB062710-F4F6-4B84-BF8A-676154656CCB@lrde.epita.fr","threadId":"10047","inReplyTo":"0CAD1C47-A396-46AA-9DC0-96BBD41EE4E4@wincent.com","subject":"Re: git push (mis ?)behavior","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-09-27T15:28:55Z","receivedAt":"2007-09-27T15:28:55Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Sep 27, 2007, at 3:30 PM, Wincent Colaiuta wrote:\n\n> El 27/9/2007, a las 15:04, Pierre Habouzit escribió:\n>\n>> There is a behavior of git-push that is the most annoying thing \n>> while\n>> working with a central-repository: `git push` without any arguments\n>> insists on pushing every local refspec that match one in origin.\n>\n> I kind of agree. Without reading the git-push man page I would \n> intuitively expect \"git push\" with no arguments to push only the \n> branch I currently have checked out, and \"git push --all\" to push all.\n\nSame thing here, got bitten the same way.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"54187","messageId":"7v3awzvrpr.fsf@gitster.siamese.dyndns.org","threadId":"10047","inReplyTo":"20070927130447.GH10289@artemis.corp","subject":"Re: git push (mis ?)behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-27T19:22:24Z","receivedAt":"2007-09-27T19:22:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit writes:\n\n> The real question is \"what does users intend when they `git push`\". In\n> a git/kernel/... like model, you don't think the same than in a\n> svn/cvs-like model. I mean, Junio or Linus likely don't push a lot to\n> their public repository. It happens probably a couple of time per day.\n> While I'm at work, it happens up way more frequentely, and I then want\n> to lazily type `git push` and not `git push origin `. it's\n> too long.\n>\n> I'm not sure what we can do about it, but I'm pretty sure it bites a\n> lot of people out there. For now I use this alias in my .gitconfig:\n>\n> p=!git-push origin `git-symbolic-ref HEAD`\n>\n> but still, it feels really wrong to me. Not to mention that git-push(1)\n> says that it has a --all option that in fact is the current default\n> behavior, hence sounds pretty useless.\n\nThe default is not --all but \"matching branches\", iow, what you\nhave never published yet never goes out.\n\nHaving said that, I would agree that in some workflows \"I am on\nthis branch and I would want to push only this branch\" would be\nthe norm, and the norm even be \"and this branch 'foo' is called\nidentically as 'foo' at the remote site as well\".\n\nDon't worry about me when discussing to change the default.\nMyself, I also often push only one or two branches. A typical\nworkflow for me while working on git.git is to prepare 'maint'\n(if there are any changes) and 'master', push them (without\npushing 'next' and 'pu') to a private \"build it to make sure\"\nrepository I have at a k.org machine which runs RH, make sure\nthey are Ok, and then continue working on integrating 'next' and\n'pu'. At the end of the day, I push out all four integration\nbranches to a separate \"publish\" area, but even this one, I rely\non the explicit configuration (remote..push) to push out\nonly the integration branches and not other branches.\n\nWe would also want to have --mirror option that acts like --all\nbut removes the refs from the remote that do not exist anymore,\nso we will be talking about updating \"git push\" in the near\nfuture anyway.\n\nSo what's the desired semantics?\n\nThe current semantics is:\n\n \"git push\" says \"you do not say to which repository?\" and\n consults \"branch..remote\" but defaults to 'origin'\n if unconfigured. \n\n \"git push \" (or using the determined as above)\n says \"you do not say which branches?\" and consults\n \"remote..push\" to find branches to push out, but\n defaults to 'matching branches' if unconfigured.\n\nWhat you would want to change is the fallback behaviour for\nunconfigured \"remote..push\". I think it is sensible to\nhave an option to make it push only the current branch. I am\nnot sure if it is sensible to make that the default (and\nintroduce --matching option to get the current behaviour) at\nthis point in 1.5.X series, but from the general usability point\nof view, I would not object to demote 'matching' to optional and\nmake 'current only' the default in 1.6.X or later.\n\nThoughts?\n"},{"id":"54191","messageId":"20070927193632.GF12427@artemis.corp","threadId":"10047","inReplyTo":"7v3awzvrpr.fsf@gitster.siamese.dyndns.org","subject":"Re: git push (mis ?)behavior","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-09-27T19:36:32Z","receivedAt":"2007-09-27T19:36:32Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Sep 27, 2007 at 07:22:24PM +0000, Junio C Hamano wrote:\n> I am not sure if it is sensible to make that the default (and\n> introduce --matching option to get the current behaviour) at this\n> point in 1.5.X series, but from the general usability point of view, I\n> would not object to demote 'matching' to optional and make 'current\n> only' the default in 1.6.X or later.\n\n Sounds like a plan to me.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54242","messageId":"9D61974D-E08D-49F6-9C88-6BE446D53C74@zib.de","threadId":"10047","inReplyTo":"7v3awzvrpr.fsf@gitster.siamese.dyndns.org","subject":"Re: git push (mis ?)behavior","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-28T06:52:47Z","receivedAt":"2007-09-28T06:52:47Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Sep 27, 2007, at 9:22 PM, Junio C Hamano wrote:\n\n>\n> So what's the desired semantics?\n>\n> The current semantics is:\n>\n> \"git push\" says \"you do not say to which repository?\" and\n> consults \"branch..remote\" but defaults to 'origin'\n> if unconfigured.\n>\n> \"git push \" (or using the determined as above)\n> says \"you do not say which branches?\" and consults\n> \"remote..push\" to find branches to push out, but\n> defaults to 'matching branches' if unconfigured.\n>\n> What you would want to change is the fallback behaviour for\n> unconfigured \"remote..push\". I think it is sensible to\n> have an option to make it push only the current branch.\n\nI'm not sure that changing the fallback behaviour for unconfigured\n\"remote..push\" is sufficient.\n\nWhen \"remote..push\" is set I'd expect \"git push\" to\nchoose only the 'right' remote..push lines, that is\nthe lines that have the current branch as the local ref.\n\"git push\" would only push the current branch, which could be pushed\nto 0 or more branches on the remote side. If no \"remote..push\"\ncontains the current branch as a local ref nothing would happen\n(maybe a warning?). If several \"remote..push\" have the current\nbranch as the local ref the branch would be pushed to several\nremote branches. But other branches than the current branch\nwould _never_ be pushed if no argument is given to 'git push'.\n\n\tSteffen\n"},{"id":"54243","messageId":"20070928065823.GB19299@artemis.corp","threadId":"10047","inReplyTo":"9D61974D-E08D-49F6-9C88-6BE446D53C74@zib.de","subject":"Re: git push (mis ?)behavior","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-09-28T06:58:23Z","receivedAt":"2007-09-28T06:58:23Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Fri, Sep 28, 2007 at 06:52:47AM +0000, Steffen Prohaska wrote:\n> \n> On Sep 27, 2007, at 9:22 PM, Junio C Hamano wrote:\n> \n> >\n> >So what's the desired semantics?\n> >\n> >The current semantics is:\n> >\n> > \"git push\" says \"you do not say to which repository?\" and\n> > consults \"branch..remote\" but defaults to 'origin'\n> > if unconfigured.\n> >\n> > \"git push \" (or using the determined as above)\n> > says \"you do not say which branches?\" and consults\n> > \"remote..push\" to find branches to push out, but\n> > defaults to 'matching branches' if unconfigured.\n> >\n> >What you would want to change is the fallback behaviour for\n> >unconfigured \"remote..push\". I think it is sensible to\n> >have an option to make it push only the current branch.\n> \n> I'm not sure that changing the fallback behaviour for unconfigured\n> \"remote..push\" is sufficient.\n> \n> When \"remote..push\" is set I'd expect \"git push\" to\n> choose only the 'right' remote..push lines, that is\n> the lines that have the current branch as the local ref.\n> \"git push\" would only push the current branch, which could be pushed\n> to 0 or more branches on the remote side. If no \"remote..push\"\n> contains the current branch as a local ref nothing would happen\n> (maybe a warning?). If several \"remote..push\" have the current\n> branch as the local ref the branch would be pushed to several\n> remote branches. But other branches than the current branch\n> would _never_ be pushed if no argument is given to 'git push'.\n\n I'm not really sure that it makes sense, as by default, git push won't\ncreate a new remote ref. So unless you have a branch that matches some\nremote ref, but that you never want to push, even when on it and typing\ngit push... there is nothing that could happen by mistake.\n\n So if you don't want to push such a branch, ever, then you should IMHO\nnot name it in a way that it matches a refspec in the first place, and\nbe safe.\n\n So I do not believe we need that extra complexity.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54244","messageId":"7vodfnqndc.fsf@gitster.siamese.dyndns.org","threadId":"10047","inReplyTo":"9D61974D-E08D-49F6-9C88-6BE446D53C74@zib.de","subject":"Re: git push (mis ?)behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-28T07:07:27Z","receivedAt":"2007-09-28T07:07:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> When \"remote..push\" is set I'd expect \"git push\" to\n> choose only the 'right' remote..push lines, that is\n> the lines that have the current branch as the local ref.\n\nThat would break the existing setup so it would not fly as a\ndefault, although it could be added as an option.\n"},{"id":"54249","messageId":"9019207B-77A5-4595-8499-807DA0460EF0@zib.de","threadId":"10047","inReplyTo":"7vodfnqndc.fsf@gitster.siamese.dyndns.org","subject":"Re: git push (mis ?)behavior","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-28T09:11:33Z","receivedAt":"2007-09-28T09:11:33Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Sep 28, 2007, at 9:07 AM, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n>\n>> When \"remote..push\" is set I'd expect \"git push\" to\n>> choose only the 'right' remote..push lines, that is\n>> the lines that have the current branch as the local ref.\n>\n> That would break the existing setup so it would not fly as a\n> default, although it could be added as an option.\n\nDo you mean 'not now' or never, i.e. not in git 1.6?\n\nWhat does 'break the existing setup' means? Pushing all branches\nthat are configured in \"remote..push\" could be done by\n\"git push \". This would be in the line with the idea that\n\"git push\" should only operate on the current branch and operations\ninvolving other local refs should be explicitly stated.\n\n\tSteffen\n"},{"id":"54252","messageId":"09A90525-8B0B-4249-904C-722BCC544B4E@zib.de","threadId":"10047","inReplyTo":"20070928065823.GB19299@artemis.corp","subject":"Re: git push (mis ?)behavior","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-28T09:26:25Z","receivedAt":"2007-09-28T09:26:25Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Sep 28, 2007, at 8:58 AM, Pierre Habouzit wrote:\n\n> On Fri, Sep 28, 2007 at 06:52:47AM +0000, Steffen Prohaska wrote:\n>>\n>> On Sep 27, 2007, at 9:22 PM, Junio C Hamano wrote:\n>>\n>>>\n>>> So what's the desired semantics?\n>>>\n>>> The current semantics is:\n>>>\n>>> \"git push\" says \"you do not say to which repository?\" and\n>>> consults \"branch..remote\" but defaults to 'origin'\n>>> if unconfigured.\n>>>\n>>> \"git push \" (or using the determined as above)\n>>> says \"you do not say which branches?\" and consults\n>>> \"remote..push\" to find branches to push out, but\n>>> defaults to 'matching branches' if unconfigured.\n>>>\n>>> What you would want to change is the fallback behaviour for\n>>> unconfigured \"remote..push\". I think it is sensible to\n>>> have an option to make it push only the current branch.\n>>\n>> I'm not sure that changing the fallback behaviour for unconfigured\n>> \"remote..push\" is sufficient.\n>>\n>> When \"remote..push\" is set I'd expect \"git push\" to\n>> choose only the 'right' remote..push lines, that is\n>> the lines that have the current branch as the local ref.\n>> \"git push\" would only push the current branch, which could be pushed\n>> to 0 or more branches on the remote side. If no \"remote..push\"\n>> contains the current branch as a local ref nothing would happen\n>> (maybe a warning?). If several \"remote..push\" have the current\n>> branch as the local ref the branch would be pushed to several\n>> remote branches. But other branches than the current branch\n>> would _never_ be pushed if no argument is given to 'git push'.\n>\n> I'm not really sure that it makes sense, as by default, git push \n> won't\n> create a new remote ref. So unless you have a branch that matches some\n> remote ref, but that you never want to push, even when on it and \n> typing\n> git push... there is nothing that could happen by mistake.\n>\n> So if you don't want to push such a branch, ever, then you should \n> IMHO\n> not name it in a way that it matches a refspec in the first place, and\n> be safe.\n\nI could have a couple of local branches typically pushed to a couple of\nremote branches. \"git push origin\" would update all remote refs.\n\nBut I may also be interested to push only the current branch I'm working\non. I may also have some pending fixes on another branch that should not\nbe pushed now. Currently I need to do \"git push origin \n:\".\n\nLet me put it as a question: How can I push changes from the current\nbranch to all remote refs it is configured to push to via \n\"remote..push\"\nwithout pushing anything else at the same time?\n\n\tSteffen\n"},{"id":"54254","messageId":"7vr6kjp1jw.fsf@gitster.siamese.dyndns.org","threadId":"10047","inReplyTo":"09A90525-8B0B-4249-904C-722BCC544B4E@zib.de","subject":"Re: git push (mis ?)behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-28T09:44:03Z","receivedAt":"2007-09-28T09:44:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> On Sep 28, 2007, at 8:58 AM, Pierre Habouzit wrote:\n>\n>> On Fri, Sep 28, 2007 at 06:52:47AM +0000, Steffen Prohaska wrote:\n>\n> But I may also be interested to push only the current branch I'm working\n> on. I may also have some pending fixes on another branch that should not\n> be pushed now. Currently I need to do \"git push origin\n> :\".\n\nSounds sensible.\n\n> Let me put it as a question: How can I push changes from the current\n> branch to all remote refs it is configured to push to via\n> \"remote..push\"\n> without pushing anything else at the same time?\n\nSorry, but I do not get you. Are you talking about pushing your\n'frotz' into more than one branches 'nitfol' and 'xyzzy' at the\nsame remote 'origin' without having to say\n\n\t$ git push origin frotz:nitfol frotz:xyzzy\n\n???\n"},{"id":"54255","messageId":"B9F497FD-BD16-4D24-8F37-0D6989155FD3@zib.de","threadId":"10047","inReplyTo":"7vr6kjp1jw.fsf@gitster.siamese.dyndns.org","subject":"Re: git push (mis ?)behavior","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-28T10:04:40Z","receivedAt":"2007-09-28T10:04:40Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Sep 28, 2007, at 11:44 AM, Junio C Hamano wrote:\n\n>> Let me put it as a question: How can I push changes from the current\n>> branch to all remote refs it is configured to push to via\n>> \"remote..push\"\n>> without pushing anything else at the same time?\n>\n> Sorry, but I do not get you. Are you talking about pushing your\n> 'frotz' into more than one branches 'nitfol' and 'xyzzy' at the\n> same remote 'origin' without having to say\n>\n> \t$ git push origin frotz:nitfol frotz:xyzzy\n>\n> ???\n\nYes. Doesn't sound like a very reasonable workflow. But you can do\nit with \"remote..push\". So I think \"git push\" should somehow\ndeal with it in a sensible way.\n\n\tSteffen\n"},{"id":"54259","messageId":"F00B74F4-7BEA-480C-B84E-A469515717B7@wincent.com","threadId":"10047","inReplyTo":"7v3awzvrpr.fsf@gitster.siamese.dyndns.org","subject":"Re: git push (mis ?)behavior","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-09-28T12:38:51Z","receivedAt":"2007-09-28T12:38:51Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 27/9/2007, a las 21:22, Junio C Hamano escribió:\n\n> What you would want to change is the fallback behaviour for\n> unconfigured \"remote..push\". I think it is sensible to\n> have an option to make it push only the current branch. I am\n> not sure if it is sensible to make that the default (and\n> introduce --matching option to get the current behaviour) at\n> this point in 1.5.X series, but from the general usability point\n> of view, I would not object to demote 'matching' to optional and\n> make 'current only' the default in 1.6.X or later.\n>\n> Thoughts?\n\nI'd certainly welcome this change for two reasons:\n\n1. It makes the behaviour more conservative (that is, harder to do \nsomething destructive and irreversible) by using the more limited \nscope by default. If you make a mistake and see that you really meant \nto push all matching branches then you can just do the push again \nwith that switch; compare that to the situation now where if you \naccidentally push all matching branches when you only wanted to push \nthe current branch then there's no way for you to \"unpush\".\n\n2. Mental baggage from working with SVK (where \"push\" means merge \nchanges back to the branch the current branch previously branched \nfrom, and \"pull\" means merge changes into the current branch from the \nbranch you previously branched from). At least for me and I suspect \nfor many others the \"current only\" default in 1.6 or latter would be \nless \"surprising\" than the current behaviour can be.\n\nCheers,\nWincent\n"},{"id":"54263","messageId":"Pine.LNX.4.64.0709281429380.28395@racer.site","threadId":"10047","inReplyTo":"9019207B-77A5-4595-8499-807DA0460EF0@zib.de","subject":"Re: git push (mis ?)behavior","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-28T13:31:56Z","receivedAt":"2007-09-28T13:31:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 28 Sep 2007, Steffen Prohaska wrote:\n\n> On Sep 28, 2007, at 9:07 AM, Junio C Hamano wrote:\n> \n> > Steffen Prohaska writes:\n> > \n> > > When \"remote..push\" is set I'd expect \"git push\" to\n> > > choose only the 'right' remote..push lines, that is\n> > > the lines that have the current branch as the local ref.\n> > \n> > That would break the existing setup so it would not fly as a\n> > default, although it could be added as an option.\n> \n> Do you mean 'not now' or never, i.e. not in git 1.6?\n\nIf it changes behaviour, and there might be people relying on the old \nbehaviour, we have to deprecate the old behaviour first. With a nice \nwarning so that people have a chance to adapt their setups. And then, \nafter a decent grace period, we can change it.\n\n> What does 'break the existing setup' means? Pushing all branches that \n> are configured in \"remote..push\" could be done by \"git push \n> \". This would be in the line with the idea that \"git push\" should \n> only operate on the current branch and operations involving other local \n> refs should be explicitly stated.\n\nPeople have scripts and aliases to help them go through the day. If one \nof those scripts or aliases stop working, that is called \"break the \nexisting setup\". ;-)\n\nCiao,\nDscho\n"},{"id":"54655","messageId":"buoprzwn5qm.fsf@dhapc248.dev.necel.com","threadId":"10047","inReplyTo":"7v3awzvrpr.fsf@gitster.siamese.dyndns.org","subject":"Re: git push (mis ?)behavior","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2007-10-03T05:10:09Z","receivedAt":"2007-10-03T05:10:09Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Junio C Hamano writes:\n> I think it is sensible to have an option to make it push only the\n> current branch. I am not sure if it is sensible to make that the\n> default.\n\nI really like the current default, it matches my mental model well: I\ngenerally use \"push\" to mean \"synchronize the remote repository with my\ncurrent one\"; if multiple branches have changed, I want those changes\npropagated too.\n\nI think changing it would be a bad idea, it just seems a pointlessly\nincompatible change. The reasons I've seen offered on this thread for\nchanging the default seem pretty weak, e.g., \"it's more conservative\"\n(but more annoying), and \"it's more like SVK\" (who cares?).\n\n-Miles\n-- \nFreedom's just another word, for nothing left to lose --Janis Joplin\n"},{"id":"54659","messageId":"7v7im4hi4e.fsf@gitster.siamese.dyndns.org","threadId":"10047","inReplyTo":"buoprzwn5qm.fsf@dhapc248.dev.necel.com","subject":"Re: git push (mis ?)behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-03T05:39:13Z","receivedAt":"2007-10-03T05:39:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader writes:\n\n> Junio C Hamano writes:\n>> I think it is sensible to have an option to make it push only the\n>> current branch. I am not sure if it is sensible to make that the\n>> default.\n>\n> I really like the current default, it matches my mental model well: I\n> generally use \"push\" to mean \"synchronize the remote repository with my\n> current one\"; if multiple branches have changed, I want those changes\n> propagated too.\n>\n> I think changing it would be a bad idea, it just seems a pointlessly\n> incompatible change. The reasons I've seen offered on this thread for\n> changing the default seem pretty weak, e.g., \"it's more conservative\"\n> (but more annoying), and \"it's more like SVK\" (who cares?).\n\nUsually we hear people complain louder on the list.\n\nPeople who are happy with the existing behaviour tend to be\nquiet, and we should be really careful not to break things for\nsilent majority.\n\nI try to stay fairly conservative, often more conservative than\nwhat I would like to be myself, for this exact reason.\n"},{"id":"54666","messageId":"0F838789-B02F-4081-8C75-ED06B551D4C0@wincent.com","threadId":"10047","inReplyTo":"buoprzwn5qm.fsf@dhapc248.dev.necel.com","subject":"Re: git push (mis ?)behavior","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-03T06:47:40Z","receivedAt":"2007-10-03T06:47:40Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 3/10/2007, a las 7:10, Miles Bader escribió:\n\n> Junio C Hamano writes:\n>> I think it is sensible to have an option to make it push only the\n>> current branch. I am not sure if it is sensible to make that the\n>> default.\n>\n> I really like the current default, it matches my mental model well: I\n> generally use \"push\" to mean \"synchronize the remote repository \n> with my\n> current one\"; if multiple branches have changed, I want those changes\n> propagated too.\n>\n> I think changing it would be a bad idea, it just seems a pointlessly\n> incompatible change. The reasons I've seen offered on this thread for\n> changing the default seem pretty weak, e.g., \"it's more conservative\"\n> (but more annoying)\n\nIt could be more annoying for some, yet a life saver for others. So \nbefore changing the default obviously we would need to get a clear \nidea of whether or not the majority would approve of such a move. \nSuch differences of opinion would be easily accommodated if the \ndefault behaviour were made configurable. That way everyone can have \nthe behaviour they want.\n\nCheers,\nWincent\n\nPS. I'm the one who mentioned SVK, but I didn't offer it as a reason \nto justify the change (I agree, more than \"weak\" it's not really any \nreason at all); I just mentioned to indicate why it is that the \ncurrent behaviour caught me off guard.\n"},{"id":"54670","messageId":"20071003073554.GA8110@artemis.corp","threadId":"10047","inReplyTo":"buoprzwn5qm.fsf@dhapc248.dev.necel.com","subject":"Re: git push (mis ?)behavior","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-03T07:35:54Z","receivedAt":"2007-10-03T07:35:54Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Oct 03, 2007 at 05:10:09AM +0000, Miles Bader wrote:\n> Junio C Hamano writes:\n> > I think it is sensible to have an option to make it push only the\n> > current branch. I am not sure if it is sensible to make that the\n> > default.\n> \n> I really like the current default, it matches my mental model well: I\n> generally use \"push\" to mean \"synchronize the remote repository with my\n> current one\"; if multiple branches have changed, I want those changes\n> propagated too.\n\n I understand that … and I know some people rely on the current\nbehavior…\n\n> I think changing it would be a bad idea, it just seems a pointlessly\n> incompatible change.\n\n There definitely is a point: with the current behaviour you sometimes\nend up pushing more than what you meant, with sometimes WIP that you\nintend to rebase, and it hurts. Git porcelains should help you avoid to\nshoot yourself in the foot, hence I think that (especially to git\nnewcomers), the current default _is_ dangerous.\n\n Though, OTOH, I believe that git push could keep the current\nbehavior. I'm also okay with the fact that git push could be\nconfigurable in that regard.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54677","messageId":"buohcl8mwd1.fsf@dhapc248.dev.necel.com","threadId":"10047","inReplyTo":"0F838789-B02F-4081-8C75-ED06B551D4C0@wincent.com","subject":"Re: git push (mis ?)behavior","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2007-10-03T08:32:42Z","receivedAt":"2007-10-03T08:32:42Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Wincent Colaiuta writes:\n> Such differences of opinion would be easily accommodated if the \n> default behaviour were made configurable. That way everyone can have \n> the behaviour they want.\n\nIndeed.\n\n-Miles\n\n-- \n\"Suppose we've chosen the wrong god. Every time we go to church we're\njust making him madder and madder.\" -- Homer Simpson\n"},{"id":"54681","messageId":"buobqbgmv6z.fsf@dhapc248.dev.necel.com","threadId":"10047","inReplyTo":"20071003073554.GA8110@artemis.corp","subject":"Re: git push (mis ?)behavior","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2007-10-03T08:57:56Z","receivedAt":"2007-10-03T08:57:56Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Pierre Habouzit writes:\n> There definitely is a point: with the current behaviour you sometimes\n> end up pushing more than what you meant, with sometimes WIP that you\n> intend to rebase, and it hurts. Git porcelains should help you avoid to\n> shoot yourself in the foot, hence I think that (especially to git\n> newcomers), the current default _is_ dangerous.\n\nWhat's \"dangerous\" for newbies, often ends up being what doesn't\ncorrespond with their mental model. I think the current default\nbehavior without any specified corresponds well to the\noperation of many other git commands (and unix command) in similar\ncircumstances: If you don't specify something to operate on, it\nessentially uses a wild card and operates on \"every reasonable thing\"\n(e.g., consider \"git commit FILE\" versus \"git commit\").\n\nEven if the default were changed, it could very well end up causing many\nproblems because it _didn't_ push as many heads as the user thought it\nwould (I don't think I'm the only one that might expect the default\naction to be \"push everything\"). When I was a git newbie, I sometimes\ngot into situations where I screwed something up because heads I thought\nhad been pushed to another system actually hadn't been.\n\nTo the extent that a command _is_ \"dangerous\", there's always a tradeoff\nbetween convenience and \"danger\". Some systems (e.g. those aimed at\nnewbies) might have as a goal to do the absolute minimum with every\ncommand and always, always, err on the side of safety. I don't think git\nis that system.\n\n-Miles\n\n-- \nYo mama's so fat when she gets on an elevator it HAS to go down.\n"},{"id":"54684","messageId":"20071003090332.GC12042@artemis.corp","threadId":"10047","inReplyTo":"buobqbgmv6z.fsf@dhapc248.dev.necel.com","subject":"Re: git push (mis ?)behavior","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-03T09:03:32Z","receivedAt":"2007-10-03T09:03:32Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Oct 03, 2007 at 08:57:56AM +0000, Miles Bader wrote:\n> Pierre Habouzit writes:\n> > There definitely is a point: with the current behaviour you sometimes\n> > end up pushing more than what you meant, with sometimes WIP that you\n> > intend to rebase, and it hurts. Git porcelains should help you avoid to\n> > shoot yourself in the foot, hence I think that (especially to git\n> > newcomers), the current default _is_ dangerous.\n> \n> What's \"dangerous\" for newbies, often ends up being what doesn't\n> correspond with their mental model. I think the current default\n> behavior without any specified corresponds well to the\n> operation of many other git commands (and unix command) in similar\n> circumstances: If you don't specify something to operate on, it\n> essentially uses a wild card and operates on \"every reasonable thing\"\n> (e.g., consider \"git commit FILE\" versus \"git commit\").\n\n Git commit is hardly a wildcard as it only operates on what you put in\nyour index, which is hardly something that happens behind your back.\n\n> To the extent that a command _is_ \"dangerous\", there's always a tradeoff\n> between convenience and \"danger\". Some systems (e.g. those aimed at\n> newbies) might have as a goal to do the absolute minimum with every\n> command and always, always, err on the side of safety. I don't think git\n> is that system.\n\n I beg to differ then. I believe that \"git push\" default behavior is\nwrong. I'm not really a newbie, and it often did not do what I meant. So\nit could also be that there isn't a sane default either. I just say the\ncurrent one can lead to gross mistakes.\n\n I know that some porcelains are risky: if you rebase \"under\" a point\nthat was published you are shooting yourself in the foot e.g.. But\ngit-rebase _is_ a command that rewrites history. You're warned from the\nfirst second you use it. But git-push is supposedly only a transport\ncommand, not something that messes with remotes history behind your\nback.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54688","messageId":"83C5420A-528A-43F0-AF8C-699B85B7AD95@wincent.com","threadId":"10047","inReplyTo":"buobqbgmv6z.fsf@dhapc248.dev.necel.com","subject":"Re: git push (mis ?)behavior","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-03T10:25:22Z","receivedAt":"2007-10-03T10:25:22Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 3/10/2007, a las 10:57, Miles Bader escribió:\n\n> To the extent that a command _is_ \"dangerous\", there's always a \n> tradeoff\n> between convenience and \"danger\". Some systems (e.g. those aimed at\n> newbies) might have as a goal to do the absolute minimum with every\n> command and always, always, err on the side of safety. I don't \n> think git\n> is that system.\n\nWhile much of this debate can be shortcircuited simply by making the \nbehaviour configurable, I would like to take you up on the point that \nyou raise here.\n\nIf we're going to talk about what kind of system Git is then consider \nthis:\n\n- it's inherently distributed and this design actively encourages \nusers to treat their local repositories as sandboxes where things are \ntried out, perfected, and then pushed out into the public via one \nmeans or another\n\n- it's built from the ground up to be good at branching and merging; \nthis, combined with my previous point, means that users are likely to \nhave multiple heads and often some of them will be \"works in \nprogress\" that aren't yet ready for publication\n\nSo it's in that light I see accidentally pushing more than you \nthought you would as \"dangerous\"; when you make this mistake you're \nbasically making stuff available that's not yet ready for \nconsumption, and by its nature this mistake is basically \nirreversible: you can't really \"unpush\" what you pushed, you can only \npush out additional amendments which correct it.\n\nSo, in this light, when you say:\n\n> What's \"dangerous\" for newbies, often ends up being what doesn't\n> correspond with their mental model.\n\nI don't know how much it has to do with mental models. I think in \nthis case it's a bit simpler than that where you make the mistake \nonce or twice and very quickly learn that \"git push\" means \"push \nwhat's in my repo\", not \"push only what's on my current branch\". It's \na *very* easy lesson to learn if you get burnt and hardly requires \nany adjustments to ones \"mental model\".\n\nI personally would be in favour of changing the default because I \ntend to work on a particular branch at a time and then want to push \n*that* out -- generally I'm thinking about one general area or one \ntask at a time, and that means one branch at a time; I almost never \nthink along the lines of getting all my branches into shape at once \nand then pushing them out in a batch. I think this is more likely to \nbe a common pattern, although obviously that remains speculation at \nthis point.\n\nChanging the default would be great for people like me; by not having \nto pass additional parameters to git-push I save some keystrokes. If \nI ever want to push everything an \"--all\" switch would do the job. \nBut if people prefer to keep the old default then there'll \nbe .gitconfig for people like me. In any case I think more people \nneed to speak up on the topic so that we can find out what most \npeople really think about changing the default.\n\nCheers,\nWincent\n"},{"id":"54690","messageId":"20071003104943.GA3017@diana.vm.bytemark.co.uk","threadId":"10047","inReplyTo":"83C5420A-528A-43F0-AF8C-699B85B7AD95@wincent.com","subject":"Re: git push (mis ?)behavior","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-03T10:49:43Z","receivedAt":"2007-10-03T10:49:43Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-03 12:25:22 +0200, Wincent Colaiuta wrote:\n\n> In any case I think more people need to speak up on the topic so\n> that we can find out what most people really think about changing\n> the default.\n\nMy vote is for changing it.\n\nBoth \"push the current branch\" and \"push all branches\" have their\nuses, and both can be specified explicitly, so no problem there. The\nproblem arises when a user expects one default but get another. There\nare two cases:\n\n 1. \"push the current branch\" is the default, but the user intended\n to push all branches. She ends up pushing only a subset of what\n she wanted, which is easily fixed once she notices what's\n happened.\n\n 2. \"push all branches\" is the default, but the user intended to push\n only the current branch. She ends up pushing a superset of what\n she wanted, which is not easily fixed if she can't be sure that\n no one else has pulled from the public repo before she notices\n what's happened.\n\nSo it all comes down to case (2) mistakes being much harder to fix\nthan case (1) mistakes. Therefore, we should change the default, since\ndoing so makes it safer.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"54692","messageId":"7v8x6kfobq.fsf@gitster.siamese.dyndns.org","threadId":"10047","inReplyTo":"20071003104943.GA3017@diana.vm.bytemark.co.uk","subject":"Re: git push (mis ?)behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-03T11:08:09Z","receivedAt":"2007-10-03T11:08:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karl Hasselström writes:\n\n> So it all comes down to case (2) mistakes being much harder to fix\n> than case (1) mistakes. Therefore, we should change the default, since\n> doing so makes it safer.\n\nI am not convinced.\n\nI've seen many new people alias \"rm\" to \"rm -i\" for this (I'd\nsay \"false\") reasoning to \"default to safer\", and end up\ntraining their fingers to say \"y\" without thinking.\n\nAlso mistakes can cut both ways. Pushing out what you did not\nintend to is what you seem to be worried about more. But not\npushing out enough and not noticing is an equally bad mistake.\n\nPeople also argue for \"default per user\". I am not really\nconvinced on that point either.\n\nYou, an expert, will get asked for help by somebody, walk up to\nhis shell prompt, and try to help and teach him by showing you\ntype, and then you suddenly notice the command does not work as\nyou expect because he set the default differently (because he\nread that configuration option on some web parge). And we will\nbe in such a cumbersome to diagnose situation _very_ often if we\nhave per-user default on many things.\n"},{"id":"54693","messageId":"889FACB5-7C62-4469-9F03-0AF92622BFFD@lrde.epita.fr","threadId":"10047","inReplyTo":"83C5420A-528A-43F0-AF8C-699B85B7AD95@wincent.com","subject":"Re: git push (mis ?)behavior","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-10-03T11:10:33Z","receivedAt":"2007-10-03T11:10:33Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Oct 3, 2007, at 12:25 PM, Wincent Colaiuta wrote:\n\n> El 3/10/2007, a las 10:57, Miles Bader escribió:\n>\n>> To the extent that a command _is_ \"dangerous\", there's always a \n>> tradeoff\n>> between convenience and \"danger\". Some systems (e.g. those aimed at\n>> newbies) might have as a goal to do the absolute minimum with every\n>> command and always, always, err on the side of safety. I don't \n>> think git\n>> is that system.\n>\n> While much of this debate can be shortcircuited simply by making \n> the behaviour configurable, I would like to take you up on the \n> point that you raise here.\n>\n> If we're going to talk about what kind of system Git is then \n> consider this:\n>\n> - it's inherently distributed and this design actively encourages \n> users to treat their local repositories as sandboxes where things \n> are tried out, perfected, and then pushed out into the public via \n> one means or another\n>\n> - it's built from the ground up to be good at branching and \n> merging; this, combined with my previous point, means that users \n> are likely to have multiple heads and often some of them will be \n> \"works in progress\" that aren't yet ready for publication\n>\n> So it's in that light I see accidentally pushing more than you \n> thought you would as \"dangerous\"; when you make this mistake you're \n> basically making stuff available that's not yet ready for \n> consumption, and by its nature this mistake is basically \n> irreversible: you can't really \"unpush\" what you pushed, you can \n> only push out additional amendments which correct it.\n>\n> So, in this light, when you say:\n>\n>> What's \"dangerous\" for newbies, often ends up being what doesn't\n>> correspond with their mental model.\n>\n> I don't know how much it has to do with mental models. I think in \n> this case it's a bit simpler than that where you make the mistake \n> once or twice and very quickly learn that \"git push\" means \"push \n> what's in my repo\", not \"push only what's on my current branch\". \n> It's a *very* easy lesson to learn if you get burnt and hardly \n> requires any adjustments to ones \"mental model\".\n>\n> I personally would be in favour of changing the default because I \n> tend to work on a particular branch at a time and then want to push \n> *that* out -- generally I'm thinking about one general area or one \n> task at a time, and that means one branch at a time; I almost never \n> think along the lines of getting all my branches into shape at once \n> and then pushing them out in a batch. I think this is more likely \n> to be a common pattern, although obviously that remains speculation \n> at this point.\n>\n> Changing the default would be great for people like me; by not \n> having to pass additional parameters to git-push I save some \n> keystrokes. If I ever want to push everything an \"--all\" switch \n> would do the job. But if people prefer to keep the old default then \n> there'll be .gitconfig for people like me. In any case I think more \n> people need to speak up on the topic so that we can find out what \n> most people really think about changing the default.\n>\n\nI completely second all that. I've been using Git for roughly 3 \nmonths and have been burnt the same way.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"54695","messageId":"3F8729D3-CC5E-478A-80E0-C199C7A1770C@wincent.com","threadId":"10047","inReplyTo":"7v8x6kfobq.fsf@gitster.siamese.dyndns.org","subject":"Re: git push (mis ?)behavior","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-03T11:22:15Z","receivedAt":"2007-10-03T11:22:15Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 3/10/2007, a las 13:08, Junio C Hamano escribió:\n\n> Also mistakes can cut both ways. Pushing out what you did not\n> intend to is what you seem to be worried about more. But not\n> pushing out enough and not noticing is an equally bad mistake.\n\nI don't think they're of the same order. If you mistakenly push out \ntoo little you can easily correct it by pushing again. But what do \nyou do if you push out too much? How do you fix that?\n\n> You, an expert, will get asked for help by somebody, walk up to\n> his shell prompt, and try to help and teach him by showing you\n> type, and then you suddenly notice the command does not work as\n> you expect because he set the default differently (because he\n> read that configuration option on some web parge). And we will\n> be in such a cumbersome to diagnose situation _very_ often if we\n> have per-user default on many things.\n\nTrue, true.\n\nCheers,\nWincent\n"},{"id":"54707","messageId":"20071003131402.GA4615@diana.vm.bytemark.co.uk","threadId":"10047","inReplyTo":"7v8x6kfobq.fsf@gitster.siamese.dyndns.org","subject":"Re: git push (mis ?)behavior","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-03T13:14:02Z","receivedAt":"2007-10-03T13:14:02Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-03 04:08:09 -0700, Junio C Hamano wrote:\n\n> Karl Hasselström writes:\n>\n> > So it all comes down to case (2) mistakes being much harder to fix\n> > than case (1) mistakes. Therefore, we should change the default,\n> > since doing so makes it safer.\n>\n> I am not convinced.\n>\n> I've seen many new people alias \"rm\" to \"rm -i\" for this (I'd say\n> \"false\") reasoning to \"default to safer\", and end up training their\n> fingers to say \"y\" without thinking.\n\nI don't think that's a good analogy here, since no one is proposing\nany kind of interactive prompt.\n\n> Also mistakes can cut both ways. Pushing out what you did not intend\n> to is what you seem to be worried about more. But not pushing out\n> enough and not noticing is an equally bad mistake.\n\nIt may be an equally bad mistake, but it's _not_ equally hard to fix.\n(And in my book, that means they aren't in fact equally bad.)\n\nYou're right that some users will train their fingers to always type\n\"git push --all\" to the point where they will push everything by\nmistake even in cases where that's not what they wanted. But the same\nthing will happen with the current default for people who almost\nalways push just a single branch, and train their fingers for that.\nAnd you just said the two mistakes were equally bad. :-)\n\n> People also argue for \"default per user\". I am not really convinced\n> on that point either.\n>\n> You, an expert, will get asked for help by somebody, walk up to his\n> shell prompt, and try to help and teach him by showing you type, and\n> then you suddenly notice the command does not work as you expect\n> because he set the default differently (because he read that\n> configuration option on some web parge). And we will be in such a\n> cumbersome to diagnose situation _very_ often if we have per-user\n> default on many things.\n\nI'm generally opposed to per-user settings for that reason. Users who\ninsist can alias \"pusha\" to \"push --all\".\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"54714","messageId":"Pine.LNX.4.64.0710031550490.28395@racer.site","threadId":"10047","inReplyTo":"20071003104943.GA3017@diana.vm.bytemark.co.uk","subject":"Re: git push (mis ?)behavior","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-03T15:27:49Z","receivedAt":"2007-10-03T15:27:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 3 Oct 2007, Karl Hasselstr?m wrote:\n\n> 2. \"push all branches\" is the default, but the user intended to push\n> only the current branch. She ends up pushing a superset of what\n> she wanted, which is not easily fixed if she can't be sure that\n> no one else has pulled from the public repo before she notices\n> what's happened.\n\nBut that is not the default. Not at all.\n\nThe default is to push the refs which the remote and the local side have \n_in common_.\n\nMaybe we should initialise the \"remote.origin.push\" variable to \n\"completely-bogus-branchname\" when you \"git init --im-a-newbie\"?\n\nCiao,\nDscho\n"},{"id":"54721","messageId":"20071003160731.GA7113@diana.vm.bytemark.co.uk","threadId":"10047","inReplyTo":"Pine.LNX.4.64.0710031550490.28395@racer.site","subject":"Re: git push (mis ?)behavior","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-03T16:07:31Z","receivedAt":"2007-10-03T16:07:31Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-03 16:27:49 +0100, Johannes Schindelin wrote:\n\n> On Wed, 3 Oct 2007, Karl Hasselstr?m wrote:\n>\n> > 2. \"push all branches\" is the default, but the user intended to\n> > push only the current branch. She ends up pushing a superset\n> > of what she wanted, which is not easily fixed if she can't be\n> > sure that no one else has pulled from the public repo before\n> > she notices what's happened.\n>\n> But that is not the default. Not at all.\n>\n> The default is to push the refs which the remote and the local side\n> have _in common_.\n\nI know, and that's what I meant by \"all branches\". Sorry for the\nsloppy language.\n\n> Maybe we should initialise the \"remote.origin.push\" variable to\n> \"completely-bogus-branchname\" when you \"git init --im-a-newbie\"?\n\nI'd rather have a suboptimal default than different defaults depending\non user settings. (See also Junio's comment on that elsewhere in this\nthread.)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"54724","messageId":"Pine.LNX.4.64.0710031718110.28395@racer.site","threadId":"10047","inReplyTo":"20071003160731.GA7113@diana.vm.bytemark.co.uk","subject":"Re: git push (mis ?)behavior","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-03T16:18:56Z","receivedAt":"2007-10-03T16:18:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 3 Oct 2007, Karl Hasselstr?m wrote:\n\n> On 2007-10-03 16:27:49 +0100, Johannes Schindelin wrote:\n> \n> > On Wed, 3 Oct 2007, Karl Hasselstr?m wrote:\n> >\n> > > 2. \"push all branches\" is the default, but the user intended to\n> > > push only the current branch. She ends up pushing a superset\n> > > of what she wanted, which is not easily fixed if she can't be\n> > > sure that no one else has pulled from the public repo before\n> > > she notices what's happened.\n> >\n> > But that is not the default. Not at all.\n> >\n> > The default is to push the refs which the remote and the local side\n> > have _in common_.\n> \n> I know, and that's what I meant by \"all branches\". Sorry for the\n> sloppy language.\n> \n> > Maybe we should initialise the \"remote.origin.push\" variable to\n> > \"completely-bogus-branchname\" when you \"git init --im-a-newbie\"?\n> \n> I'd rather have a suboptimal default than different defaults depending\n> on user settings. (See also Junio's comment on that elsewhere in this\n> thread.)\n\nThis thread is getting painful. Lot's of \"I want\"s, but nobody to date \ncame up with a solution that makes both oldtimers and newtimers happy.\n\nCiao,\nDscho\n"},{"id":"54725","messageId":"FE701A99-E21C-48C3-BF08-25AE2E3665D6@wincent.com","threadId":"10047","inReplyTo":"Pine.LNX.4.64.0710031550490.28395@racer.site","subject":"Re: git push (mis ?)behavior","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-03T16:26:00Z","receivedAt":"2007-10-03T16:26:00Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 3/10/2007, a las 17:27, Johannes Schindelin escribió:\n\n> On Wed, 3 Oct 2007, Karl Hasselström wrote:\n>\n>> 2. \"push all branches\" is the default, but the user intended to \n>> push\n>> only the current branch. She ends up pushing a superset of what\n>> she wanted, which is not easily fixed if she can't be sure that\n>> no one else has pulled from the public repo before she notices\n>> what's happened.\n>\n> But that is not the default. Not at all.\n>\n> The default is to push the refs which the remote and the local side \n> have\n> _in common_.\n\nYes, that's already been covered in this thread, probably in the \nfirst or second post, and (at least I hope) we've all read it and \ntake it as given.\n\nReplace \"push all branches\" with \"push all refs that both sides have \nin common\", which is presumably what Karl meant, and the concerns are \nstill there.\n\n> Maybe we should initialise the \"remote.origin.push\" variable to\n> \"completely-bogus-branchname\" when you \"git init --im-a-newbie\"?\n\nHow is this comment supposed to help in any way? Please try to think \nabout the image you're putting across; as an relatively active and \nprominent contributer in the Git community you are part of the \"face\" \nof the community.\n\nCheers,\nWincent\n"},{"id":"54726","messageId":"20071003162816.GA17403@artemis.corp","threadId":"10047","inReplyTo":"Pine.LNX.4.64.0710031718110.28395@racer.site","subject":"Re: git push (mis ?)behavior","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-03T16:28:16Z","receivedAt":"2007-10-03T16:28:16Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Oct 03, 2007 at 04:18:56PM +0000, Johannes Schindelin wrote:\n> This thread is getting painful. Lot's of \"I want\"s, but nobody to date \n> came up with a solution that makes both oldtimers and newtimers happy.\n\nI think I made a proposal that tries to reach some kind of consensus:\n\n`git push`::\n no arguments given just pushes the current branch you're on, into\n origin, if a refspec matches.\n\n`git push `::\n works like now (aka pushes all branches that match a remote branch\n in the given remote).\n\nThis way, you can have current \"git push\" using \"git push origin\", but\nyou also have a convenient way to push only the current branch into your\ndefault remote repository without needing to spell out:\n\n $ git push origin `git symbolic-ref HEAD`\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54727","messageId":"Pine.LNX.4.64.0710031742400.28395@racer.site","threadId":"10047","inReplyTo":"20071003162816.GA17403@artemis.corp","subject":"Re: git push (mis ?)behavior","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-03T16:44:39Z","receivedAt":"2007-10-03T16:44:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 3 Oct 2007, Pierre Habouzit wrote:\n\n> On Wed, Oct 03, 2007 at 04:18:56PM +0000, Johannes Schindelin wrote:\n> > This thread is getting painful. Lot's of \"I want\"s, but nobody to date \n> > came up with a solution that makes both oldtimers and newtimers happy.\n> \n> I think I made a proposal that tries to reach some kind of consensus:\n> \n> `git push`::\n> no arguments given just pushes the current branch you're on, into\n> origin, if a refspec matches.\n\nI use that sometimes, and I do not want only the current branch to be \npushed.\n\n> `git push `::\n> works like now (aka pushes all branches that match a remote branch\n> in the given remote).\n\nThat would make things inconsistent, and inconsistent things are always \nhard to explain.\n\n> This way, you can have current \"git push\" using \"git push origin\", but \n> you also have a convenient way to push only the current branch into your \n> default remote repository without needing to spell out:\n> \n> $ git push origin `git symbolic-ref HEAD`\n\nI wonder how hard it would be to teach _everybody_ to specify _exactly_ \nwhat they want.\n\nOf course, we'd need an \"--existing\" option to git-push to trigger the \nbehaviour that we have right now.\n\nCiao,\nDscho\n"},{"id":"54730","messageId":"20071003170241.GA7571@diana.vm.bytemark.co.uk","threadId":"10047","inReplyTo":"Pine.LNX.4.64.0710031742400.28395@racer.site","subject":"Re: git push (mis ?)behavior","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-03T17:02:41Z","receivedAt":"2007-10-03T17:02:41Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-03 17:44:39 +0100, Johannes Schindelin wrote:\n\n> I wonder how hard it would be to teach _everybody_ to specify\n> _exactly_ what they want.\n>\n> Of course, we'd need an \"--existing\" option to git-push to trigger\n> the behaviour that we have right now.\n\nI could _definitely_ live with that. If the branch config doesn't say\nwhat to do when no arguments are given, then demand a specification on\nthe command line.\n\nI'll shut up on this topic now, though, since I'm not exactly helping\nwith the patch/opinion ratio.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"54828","messageId":"717D7260-CE23-4397-8B13-264309094423@zib.de","threadId":"10047","inReplyTo":"20071003170241.GA7571@diana.vm.bytemark.co.uk","subject":"Re: git push (mis ?)behavior","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-04T14:47:32Z","receivedAt":"2007-10-04T14:47:32Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 3, 2007, at 7:02 PM, Karl Hasselström wrote:\n\n> On 2007-10-03 17:44:39 +0100, Johannes Schindelin wrote:\n>\n>> I wonder how hard it would be to teach _everybody_ to specify\n>> _exactly_ what they want.\n>>\n>> Of course, we'd need an \"--existing\" option to git-push to trigger\n>> the behaviour that we have right now.\n>\n> I could _definitely_ live with that. If the branch config doesn't say\n> what to do when no arguments are given, then demand a specification on\n> the command line.\n>\n> I'll shut up on this topic now, though, since I'm not exactly helping\n> with the patch/opinion ratio.\n\nHere is an interesting related pitfall where my expectations about\nthe behaviour of git push in relation with tracking branches were\nwrong. I should have know better, but I somehow forgot the details.\nI expected that the following would establish a two-way link, not\nonly a one way link:\n\n git checkout --track -b mynext origin/next\n\nsets up a tracking branch and \"git pull\" fetches and merges changes\nfrom origin/next as expected.\n\nI somehow expected that \"git push\" would push changes from mynext to\norigin/next. But it doesn't. It would only do so if I had chosen\nthe same name for the local branch, that is\n\n git checkout --track -b next origin/next\n\nwould have set up a two-way link -- but maybe only as long as I don't\nhave other push lines in my config file. I'm not sure about the last\npoint.\n\nI do not find it very intuitive to mangle the push behaviour into the\nnaming of the local branch. I think it would be a good idea if the\ntwo commands above would either both setup a pull/push relation\nor both would setup a pull-only relation. If pull-only would be the\ndefault another switch could be provided to establish a pull/push\nrelation, like\n\n git checkout --track --push -b mynext origin/next\n\nComments?\n\n\tSteffen"},{"id":"54841","messageId":"204B0DD6-54B0-4436-AFC6-ABDA4510E5D5@wincent.com","threadId":"10047","inReplyTo":"717D7260-CE23-4397-8B13-264309094423@zib.de","subject":"Re: git push (mis ?)behavior","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-04T15:54:21Z","receivedAt":"2007-10-04T15:54:21Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 4/10/2007, a las 16:47, Steffen Prohaska escribió:\n\n> On Oct 3, 2007, at 7:02 PM, Karl Hasselström wrote:\n>\n>> On 2007-10-03 17:44:39 +0100, Johannes Schindelin wrote:\n>>\n>>> I wonder how hard it would be to teach _everybody_ to specify\n>>> _exactly_ what they want.\n>>>\n>>> Of course, we'd need an \"--existing\" option to git-push to trigger\n>>> the behaviour that we have right now.\n>>\n>> I could _definitely_ live with that. If the branch config doesn't say\n>> what to do when no arguments are given, then demand a \n>> specification on\n>> the command line.\n>>\n>> I'll shut up on this topic now, though, since I'm not exactly helping\n>> with the patch/opinion ratio.\n>\n> Here is an interesting related pitfall where my expectations about\n> the behaviour of git push in relation with tracking branches were\n> wrong. I should have know better, but I somehow forgot the details.\n> I expected that the following would establish a two-way link, not\n> only a one way link:\n>\n> git checkout --track -b mynext origin/next\n>\n> sets up a tracking branch and \"git pull\" fetches and merges changes\n> from origin/next as expected.\n>\n> I somehow expected that \"git push\" would push changes from mynext to\n> origin/next. But it doesn't. It would only do so if I had chosen\n> the same name for the local branch, that is\n>\n> git checkout --track -b next origin/next\n>\n> would have set up a two-way link -- but maybe only as long as I don't\n> have other push lines in my config file. I'm not sure about the last\n> point.\n>\n> I do not find it very intuitive to mangle the push behaviour into the\n> naming of the local branch. I think it would be a good idea if the\n> two commands above would either both setup a pull/push relation\n> or both would setup a pull-only relation. If pull-only would be the\n> default another switch could be provided to establish a pull/push\n> relation, like\n>\n> git checkout --track --push -b mynext origin/next\n>\n> Comments?\n\nInteresting. To me that doesn't seem to be intuitive at all. I \nactually think it makes a lot of sense for the relationship to be \n\"one way\" in the absence of matching ref names.\n\nBasically, the distributed model works because you know that if you \nhave the same commit hash in two repositories you're talking about \nthe same thing. Same thing goes for branches; if you expect to be \nable to push back upstream then it's natural to expect that that \nshould only work if you have the same ref name to identify the \"what\" \nthat you're actually pushing to.\n\nCheers,\nWincent\n"},{"id":"54849","messageId":"04A74C2E-272B-4F5C-9254-11C9244091AF@zib.de","threadId":"10047","inReplyTo":"204B0DD6-54B0-4436-AFC6-ABDA4510E5D5@wincent.com","subject":"Re: git push (mis ?)behavior","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-04T16:24:23Z","receivedAt":"2007-10-04T16:24:23Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 4, 2007, at 5:54 PM, Wincent Colaiuta wrote:\n\n>> I do not find it very intuitive to mangle the push behaviour into the\n>> naming of the local branch. I think it would be a good idea if the\n>> two commands above would either both setup a pull/push relation\n>> or both would setup a pull-only relation. If pull-only would be the\n>> default another switch could be provided to establish a pull/push\n>> relation, like\n>>\n>> git checkout --track --push -b mynext origin/next\n>>\n>> Comments?\n>\n> Interesting. To me that doesn't seem to be intuitive at all. I \n> actually think it makes a lot of sense for the relationship to be \n> \"one way\" in the absence of matching ref names.\n>\n> Basically, the distributed model works because you know that if you \n> have the same commit hash in two repositories you're talking about \n> the same thing. Same thing goes for branches; if you expect to be \n> able to push back upstream then it's natural to expect that that \n> should only work if you have the same ref name to identify the \n> \"what\" that you're actually pushing to.\n\nBut how do multiple remotes fit into your model? Maybe my example\nabove was a bit to simple. How about this one:\n\n git checkout --track --push -b masterA remoteA/master\n git checkout --track --push -b masterB remoteB/master\n\nI understand what it means because I devised my local naming model.\nThe model could look totally wrong to you, but it's in my repository.\nYou'd never see it. But if it fits my mental model, why should git\nenforce its master-means-always-master-and-must-not-be-named-differently\nmodel?\n\n\tSteffen\n"},{"id":"54860","messageId":"E9EA8C5A-B56F-4A27-ACC8-0D6686D51BEF@wincent.com","threadId":"10047","inReplyTo":"04A74C2E-272B-4F5C-9254-11C9244091AF@zib.de","subject":"Re: git push (mis ?)behavior","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-04T17:49:23Z","receivedAt":"2007-10-04T17:49:23Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 4/10/2007, a las 18:24, Steffen Prohaska escribió:\n\n> On Oct 4, 2007, at 5:54 PM, Wincent Colaiuta wrote:\n>\n>>> I do not find it very intuitive to mangle the push behaviour into \n>>> the\n>>> naming of the local branch. I think it would be a good idea if the\n>>> two commands above would either both setup a pull/push relation\n>>> or both would setup a pull-only relation. If pull-only would be the\n>>> default another switch could be provided to establish a pull/push\n>>> relation, like\n>>>\n>>> git checkout --track --push -b mynext origin/next\n>>>\n>>> Comments?\n>>\n>> Interesting. To me that doesn't seem to be intuitive at all. I \n>> actually think it makes a lot of sense for the relationship to be \n>> \"one way\" in the absence of matching ref names.\n>>\n>> Basically, the distributed model works because you know that if \n>> you have the same commit hash in two repositories you're talking \n>> about the same thing. Same thing goes for branches; if you expect \n>> to be able to push back upstream then it's natural to expect that \n>> that should only work if you have the same ref name to identify \n>> the \"what\" that you're actually pushing to.\n>\n> But how do multiple remotes fit into your model? Maybe my example\n> above was a bit to simple. How about this one:\n>\n> git checkout --track --push -b masterA remoteA/master\n> git checkout --track --push -b masterB remoteB/master\n>\n> I understand what it means because I devised my local naming model.\n> The model could look totally wrong to you, but it's in my repository.\n> You'd never see it. But if it fits my mental model, why should git\n> enforce its master-means-always-master-and-must-not-be-named- \n> differently\n> model?\n\nI think I'll leave it up to someone who knows a bit more than me to \nanswer that one... It's not a use case I've ever sought out as I \nusually only work with one upstream remote. Sorry I don't have \nanything intelligent to add.\n\nCheers,\nWincent\n"},{"id":"55226","messageId":"20071009050533.GA2968@efreet.light.src","threadId":"10047","inReplyTo":"7vodfnqndc.fsf@gitster.siamese.dyndns.org","subject":"Re: git push (mis ?)behavior","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-10-09T05:05:33Z","receivedAt":"2007-10-09T05:05:33Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Fri, Sep 28, 2007 at 00:07:27 -0700, Junio C Hamano wrote:\n> Steffen Prohaska writes:\n> \n> > When \"remote..push\" is set I'd expect \"git push\" to\n> > choose only the 'right' remote..push lines, that is\n> > the lines that have the current branch as the local ref.\n\nI would like this for another reason and maybe in slightly different way.\nBasically I would have configured something along the lines:\n [remote \"origin\"]\n push = refs/heads/*:refs/heads/jahu/*\nand would want to choose, via option, whether I want to push all the branches\nor just the current one, but in any case with the renaming specified.\n\nThe idea behind this is to have a shared repository, but not shared branches.\nEverybody would have a subdirectory in refs/heads where he could push\nanything that the others should see and than somebody else (either designated\nintegrator, or just anybody different) would do a quick review and merge it\ninto master.\n\nNow I could of course push out everything, but usually I'd want to push\nexactly the current branch, renaming it by the rule given, whether it already\nexisted in origin or not. Than there can be eg. a post-receive hook notifying\nthe integrator that there is something for review.\n\n> That would break the existing setup so it would not fly as a\n> default, although it could be added as an option.\n\nWe can have an option and/or we can have some new parameter in .git/config.\nMaybe:\n push = refs/heads/*:refs/heads/jahu/*\nwould mean to push always (ie. everything under refs/heads) and eg.:\n push = !refs/heads/*:refs/heads/jahu/*\nwould mean to push just current branch if it matches. Mixed setups would be\npossible:\n push = refs/heads/*:refs/heads/jahu/* !master:master !next:next\nwould mean push everything to jahu/ and if current is master, push it to\nmaster, or if current is next, push it to next.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"55236","messageId":"5C3443FD-DEC3-4EDC-B10B-0C4307EF9492@zib.de","threadId":"10047","inReplyTo":"20071009050533.GA2968@efreet.light.src","subject":"Re: git push (mis ?)behavior","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-09T07:23:42Z","receivedAt":"2007-10-09T07:23:42Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 9, 2007, at 7:05 AM, Jan Hudec wrote:\n\n> On Fri, Sep 28, 2007 at 00:07:27 -0700, Junio C Hamano wrote:\n>> Steffen Prohaska writes:\n>>\n>>> When \"remote..push\" is set I'd expect \"git push\" to\n>>> choose only the 'right' remote..push lines, that is\n>>> the lines that have the current branch as the local ref.\n>\n> I would like this for another reason and maybe in slightly \n> different way.\n> Basically I would have configured something along the lines:\n> [remote \"origin\"]\n> push = refs/heads/*:refs/heads/jahu/*\n> and would want to choose, via option, whether I want to push all \n> the branches\n> or just the current one, but in any case with the renaming specified.\n>\n> The idea behind this is to have a shared repository, but not shared \n> branches.\n> Everybody would have a subdirectory in refs/heads where he could push\n> anything that the others should see and than somebody else (either \n> designated\n> integrator, or just anybody different) would do a quick review and \n> merge it\n> into master.\n>\n> Now I could of course push out everything, but usually I'd want to \n> push\n> exactly the current branch, renaming it by the rule given, whether \n> it already\n> existed in origin or not. Than there can be eg. a post-receive hook \n> notifying\n> the integrator that there is something for review.\n\nI had a similar scenario in mind. So a more general question is the \nfollowing:\n\nGit well supports the clone from read-only and push to private repo \nscheme.\nIn this case all repositories you're pushing to are by definition _your_\nrepositories. The only question left is, which subset of your \nbranches are\npushed. But there's no need for renaming during push.\n\nNow the question is, what is a sensible workflow on a shared repository?\n\nOne option is to use some kind of private 'namespace' scheme. For \nexample\ndevelopers should push their topics to a branch prefixed with their \nname,\nor to a 'subdirectory' ref/heads/needsreview/*.\n\nThis workflow may require to 'rename' branches during push. So how \ncan this\nbe supported by git? Supporting only renames that add a prefix, as \nsuggested\nby Jan, may be reasonable restriction.\n\n\tSteffen\n"}]}