{"thread":{"id":"16081","subject":"Using the --track option when creating a branch","startedAt":"2008-10-29T15:23:54Z","lastAt":"2008-11-02T04:23:59Z","messageCount":23,"participants":["Bill Lear","Santi Béjar","Sam Vilain","Andreas Ericsson","Samuel Tardieu","Pierre Habouzit","Marc Branchaud","Jakub Narebski","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"94191","messageId":"18696.32778.842933.486171@lisa.zopyra.com","threadId":"16081","inReplyTo":null,"subject":"Using the --track option when creating a branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2008-10-29T15:23:54Z","receivedAt":"2008-10-29T15:23:54Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"We have had a few \"crossed stream\" problems when developers are\nworking on a local branch and they do an unguarded git push/pull,\nwhen they really intended to do git push/pull origin branchname.\n\nWe use git in a way that makes it desirable for us to only push/pull\nto the same remote branch. So, if I'm in branch X, I want 'git push'\nto push to origin/X, and 'git pull' to fetch into origin/X and then\nmerge into X from origin/X.\n\nIn other words, we want git push/pull to behave in branches other than\nmaster the same way it does when in master.\n\nI have discovered the '--track' option when creating a local branch,\nand this appears to me to be the thing that gives us the desired\nbehavior.\n\nBefore I tell the rest of the team that this is the correct way\nto do things, I need to be sure I am correct, so if anyone here\ncan confirm or deny this, I'd appreciate it.\n\nAlso, once a branch has been created, how can we add a '--track' option\nafter the fact?\n\nFinally, is there a 'global' config setting that would set this behavior\nfor all repos (new or existing)?\n\nWe are using git 1.6.* versions here, mostly.\n\nThanks.\n\n\nBill\n"},{"id":"94194","messageId":"adf1fd3d0810290925s493cdc6oc7534904c864db28@mail.gmail.com","threadId":"16081","inReplyTo":"18696.32778.842933.486171@lisa.zopyra.com","subject":"Re: Using the --track option when creating a branch","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2008-10-29T16:25:37Z","receivedAt":"2008-10-29T16:25:37Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Wed, Oct 29, 2008 at 4:23 PM, Bill Lear wrote:\n> We have had a few \"crossed stream\" problems when developers are\n> working on a local branch and they do an unguarded git push/pull,\n> when they really intended to do git push/pull origin branchname.\n>\n> We use git in a way that makes it desirable for us to only push/pull\n> to the same remote branch. So, if I'm in branch X, I want 'git push'\n> to push to origin/X, and 'git pull' to fetch into origin/X and then\n> merge into X from origin/X.\n>\n> In other words, we want git push/pull to behave in branches other than\n> master the same way it does when in master.\n>\n> I have discovered the '--track' option when creating a local branch,\n> and this appears to me to be the thing that gives us the desired\n> behavior.\n\nbranch.autosetupmerge controls if --track is used by default (it is\ntrue by default since a long time)\n(See \"git help config\" for details)\n\n>\n> Before I tell the rest of the team that this is the correct way\n> to do things, I need to be sure I am correct, so if anyone here\n> can confirm or deny this, I'd appreciate it.\n\nIt should just work (at least in the lastest releases) when creating a\nbranch from a remote branch.\n\n$ git checkout -b X origin/X\nor\n$ git branch X origin/X\nBranch X set up to track remote branch refs/remotes/origin/X\n\n>\n> Also, once a branch has been created, how can we add a '--track' option\n> after the fact?\n\nIt it just two configs (apart from the remote repository). A help\nmessage should appear when using \"git pull\" without arguments and it\ncannot figure out the branch to merge:\n\n$ # currently in branch next\n$ git pull\nYou asked me to pull without telling me which branch you\nwant to merge with, and 'branch.next.merge' in\nyour configuration file does not tell me either. Please\nname which branch you want to merge on the command line and\ntry again (e.g. 'git pull ').\nSee git-pull(1) for details on the refspec.\n\nIf you often merge with the same branch, you may want to\nconfigure the following variables in your configuration\nfile:\n\n branch.next.remote = \n branch.next.merge = \n remote..url = \n remote..fetch = \n\nSee git-config(1) for details.\n\n[end]\n\nso to add it after the fact you should execute:\n\n$ git config branch.next.remote origin\n$ git config branch.next.merge refs/heads/next\n\n>\n> Finally, is there a 'global' config setting that would set this behavior\n> for all repos (new or existing)?\n\nSee above.\n\n>\n> We are using git 1.6.* versions here, mostly.\n>\n\nSanti\n"},{"id":"94227","messageId":"18696.51354.329776.550395@lisa.zopyra.com","threadId":"16081","inReplyTo":"adf1fd3d0810290925s493cdc6oc7534904c864db28@mail.gmail.com","subject":"Re: Using the --track option when creating a branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2008-10-29T20:33:30Z","receivedAt":"2008-10-29T20:33:30Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, October 29, 2008 at 17:25:37 (+0100) Santi Béjar writes:\n>On Wed, Oct 29, 2008 at 4:23 PM, Bill Lear wrote:\n>> We have had a few \"crossed stream\" problems when developers are\n>> working on a local branch and they do an unguarded git push/pull,\n>> when they really intended to do git push/pull origin branchname.\n>>\n>> We use git in a way that makes it desirable for us to only push/pull\n>> to the same remote branch. So, if I'm in branch X, I want 'git push'\n>> to push to origin/X, and 'git pull' to fetch into origin/X and then\n>> merge into X from origin/X.\n>>\n>> In other words, we want git push/pull to behave in branches other than\n>> master the same way it does when in master.\n>>\n>> I have discovered the '--track' option when creating a local branch,\n>> and this appears to me to be the thing that gives us the desired\n>> behavior.\n>\n>branch.autosetupmerge controls if --track is used by default (it is\n>true by default since a long time)\n>(See \"git help config\" for details)\n\nAh, problem solved then. I'll just have everyone upgrade to the\nlatest git. Thanks very much, Santi.\n\n\nBill\n"},{"id":"94261","messageId":"1225343538.10803.9.camel@maia.lan","threadId":"16081","inReplyTo":"18696.32778.842933.486171@lisa.zopyra.com","subject":"Re: Using the --track option when creating a branch","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-30T05:12:18Z","receivedAt":"2008-10-30T05:12:18Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:\n> We use git in a way that makes it desirable for us to only push/pull\n> to the same remote branch. So, if I'm in branch X, I want 'git push'\n> to push to origin/X, and 'git pull' to fetch into origin/X and then\n> merge into X from origin/X.\n> \n> In other words, we want git push/pull to behave in branches other than\n> master the same way it does when in master.\n> \n> I have discovered the '--track' option when creating a local branch,\n> and this appears to me to be the thing that gives us the desired\n> behavior.\n\nAs things currently stand this is not achievable behaviour. The\nbehaviour of 'git push' is to push all matching refs. If you are lucky\nthis is what you intended, but it also pushes any changes to *other*\nbranches that you have made.\n\nI have tabled a change proposal to make it work as you suggest in a\nseparate thread.\n\nSam\n"},{"id":"94278","messageId":"18697.41702.241183.408377@lisa.zopyra.com","threadId":"16081","inReplyTo":"1225343538.10803.9.camel@maia.lan","subject":"Re: Using the --track option when creating a branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2008-10-30T12:04:54Z","receivedAt":"2008-10-30T12:04:54Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:\n>On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:\n>> We use git in a way that makes it desirable for us to only push/pull\n>> to the same remote branch. So, if I'm in branch X, I want 'git push'\n>> to push to origin/X, and 'git pull' to fetch into origin/X and then\n>> merge into X from origin/X.\n>> \n>> In other words, we want git push/pull to behave in branches other than\n>> master the same way it does when in master.\n>> \n>> I have discovered the '--track' option when creating a local branch,\n>> and this appears to me to be the thing that gives us the desired\n>> behavior.\n>\n>As things currently stand this is not achievable behaviour. The\n>behaviour of 'git push' is to push all matching refs. If you are lucky\n>this is what you intended, but it also pushes any changes to *other*\n>branches that you have made.\n>\n>I have tabled a change proposal to make it work as you suggest in a\n>separate thread.\n\nOk, now I'm confused. The ONLY thing I want to prevent is the\n\"crossing of streams\" issue. If I am on branch X and issue 'git\npush', I want X, and ONLY X, to be pushed to the remote repository's X\nbranch --- I don't care if other branches are pushed to their\nrespective remote branches, as long as they don't get merged to X.\n\nSo, are you saying that Santi was incorrect, and that in fact\nthe push will result in a merge of the branches?\n\n\nBill\n"},{"id":"94279","messageId":"18697.42140.459170.891195@lisa.zopyra.com","threadId":"16081","inReplyTo":"18697.41702.241183.408377@lisa.zopyra.com","subject":"Re: Using the --track option when creating a branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2008-10-30T12:12:12Z","receivedAt":"2008-10-30T12:12:12Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Thursday, October 30, 2008 at 06:04:54 (-0600) Bill Lear writes:\n>On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:\n>>On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:\n>>> We use git in a way that makes it desirable for us to only push/pull\n>>> to the same remote branch. So, if I'm in branch X, I want 'git push'\n>>> to push to origin/X, and 'git pull' to fetch into origin/X and then\n>>> merge into X from origin/X.\n>>> \n>>> In other words, we want git push/pull to behave in branches other than\n>>> master the same way it does when in master.\n>>> \n>>> I have discovered the '--track' option when creating a local branch,\n>>> and this appears to me to be the thing that gives us the desired\n>>> behavior.\n>>\n>>As things currently stand this is not achievable behaviour. The\n>>behaviour of 'git push' is to push all matching refs. If you are lucky\n>>this is what you intended, but it also pushes any changes to *other*\n>>branches that you have made.\n>>\n>>I have tabled a change proposal to make it work as you suggest in a\n>>separate thread.\n>\n>Ok, now I'm confused. The ONLY thing I want to prevent is the\n>\"crossing of streams\" issue. If I am on branch X and issue 'git\n>push', I want X, and ONLY X, to be pushed to the remote repository's X\n>branch --- I don't care if other branches are pushed to their\n>respective remote branches, as long as they don't get merged to X.\n\nOh, and also the same thing for 'git pull' --- sorry to leave that out.\n\n\nBill\n"},{"id":"94280","messageId":"4909A7C4.30507@op5.se","threadId":"16081","inReplyTo":"18697.42140.459170.891195@lisa.zopyra.com","subject":"Re: Using the --track option when creating a branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-30T12:25:40Z","receivedAt":"2008-10-30T12:25:40Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Bill Lear wrote:\n> On Thursday, October 30, 2008 at 06:04:54 (-0600) Bill Lear writes:\n>> On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:\n>>> On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:\n>>>> We use git in a way that makes it desirable for us to only push/pull\n>>>> to the same remote branch. So, if I'm in branch X, I want 'git push'\n>>>> to push to origin/X, and 'git pull' to fetch into origin/X and then\n>>>> merge into X from origin/X.\n>>>>\n>>>> In other words, we want git push/pull to behave in branches other than\n>>>> master the same way it does when in master.\n>>>>\n>>>> I have discovered the '--track' option when creating a local branch,\n>>>> and this appears to me to be the thing that gives us the desired\n>>>> behavior.\n>>> As things currently stand this is not achievable behaviour. The\n>>> behaviour of 'git push' is to push all matching refs. If you are lucky\n>>> this is what you intended, but it also pushes any changes to *other*\n>>> branches that you have made.\n>>>\n>>> I have tabled a change proposal to make it work as you suggest in a\n>>> separate thread.\n>> Ok, now I'm confused. The ONLY thing I want to prevent is the\n>> \"crossing of streams\" issue. If I am on branch X and issue 'git\n>> push', I want X, and ONLY X, to be pushed to the remote repository's X\n>> branch --- I don't care if other branches are pushed to their\n>> respective remote branches, as long as they don't get merged to X.\n> \n> Oh, and also the same thing for 'git pull' --- sorry to leave that out.\n> \n\nThis particular bikeshed was painted a long time ago, with the consensus\ngoing in favour of \"git push\" pushing all *matching* refspecs.\n\nTo convince people, I think you need to either come up with arguments\nnullifying all the arguments *for* pushing all matching refspecs along\nwith patches to make the default configurable, with your preferred way\nas a default, and a nifty enough shorthand for pushing/fetching all\nmatching refspecs. For preference, they should be at least 3 separate\npatches.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"94281","messageId":"adf1fd3d0810300541l7fb8b64nf9587fec4e481c58@mail.gmail.com","threadId":"16081","inReplyTo":"18697.41702.241183.408377@lisa.zopyra.com","subject":"Re: Using the --track option when creating a branch","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2008-10-30T12:41:26Z","receivedAt":"2008-10-30T12:41:26Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Thu, Oct 30, 2008 at 1:04 PM, Bill Lear wrote:\n> On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:\n>>On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:\n>>> We use git in a way that makes it desirable for us to only push/pull\n>>> to the same remote branch. So, if I'm in branch X, I want 'git push'\n>>> to push to origin/X, and 'git pull' to fetch into origin/X and then\n>>> merge into X from origin/X.\n>>>\n>>> In other words, we want git push/pull to behave in branches other than\n>>> master the same way it does when in master.\n>>>\n>>> I have discovered the '--track' option when creating a local branch,\n>>> and this appears to me to be the thing that gives us the desired\n>>> behavior.\n>>\n>>As things currently stand this is not achievable behaviour. The\n>>behaviour of 'git push' is to push all matching refs. If you are lucky\n>>this is what you intended, but it also pushes any changes to *other*\n>>branches that you have made.\n>>\n>>I have tabled a change proposal to make it work as you suggest in a\n>>separate thread.\n>\n> Ok, now I'm confused. The ONLY thing I want to prevent is the\n> \"crossing of streams\" issue. If I am on branch X and issue 'git\n> push', I want X, and ONLY X, to be pushed to the remote repository's X\n> branch --- I don't care if other branches are pushed to their\n> respective remote branches, as long as they don't get merged to X.\n\nNo branches will get merged in a push.\n\n>\n> So, are you saying that Santi was incorrect, and that in fact\n> the push will result in a merge of the branches?\n\nSorry, I was (partly) incorrect because I was only talking about pull.\nFor push you can add a \"push = HEAD\" config to the remote and then the\n\"git push\" will only push the current branch (with the corresponding\nmatching remote branch).\n\n$ git config remote.origin.push HEAD\n\nStrictly speaking when you push (with the default config or with the\nabove trick) you push matching branches (it doesn't matter what is the\nbranch..merge). Currently there is no way to say \"push to the\ncorresponding tracking branch\"\n\nStill I think this will work as you want (as long as your local and\nremote branch have the same name):\n\n$ git clone $url\n$ cd path\n$ git config remote.origin.push HEAD\n$ git checkout -b branch origin/branch\n$ work, commit,...\n$ git push\n\nHTH,\nSanti\n"},{"id":"94285","messageId":"2008-10-30-14-52-52+trackit+sam@rfc1149.net","threadId":"16081","inReplyTo":"4909A7C4.30507@op5.se","subject":"Re: Using the --track option when creating a branch","fromName":"Samuel Tardieu","fromEmail":"sam@rfc1149.net","sentAt":"2008-10-30T13:52:52Z","receivedAt":"2008-10-30T13:52:52Z","isPatch":false,"sender":{"key":"sam@rfc1149.net","avatar":"https://avatars.githubusercontent.com/u/44656?v=4"},"body":">>>>> \"Andreas\" == Andreas Ericsson writes:\n\nAndreas> This particular bikeshed was painted a long time ago, with\nAndreas> the consensus going in favour of \"git push\" pushing all\nAndreas> *matching* refspecs.\n\nI still don't understand why this is useful, especially when git push\nalready has a \"--all\" option.\n\nI know that I've never had the intent to push all the refs without\nthinking about it first. Most of the time, I intend to push only\nthe current branch I am in.\n\nThe current behaviour made me remove the branches I was not actively\non locally, because I would get errors from \"git push\" all the time\nsaying that I was not up-to-date in those branches.\n\nNote that the \"git pull\" issue is completely different, as it merges\nor fast forwards the current branch only.\n\n Sam\n-- \nSamuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/\n"},{"id":"94286","messageId":"4909BF58.9010500@op5.se","threadId":"16081","inReplyTo":"2008-10-30-14-52-52+trackit+sam@rfc1149.net","subject":"Re: Using the --track option when creating a branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-30T14:06:16Z","receivedAt":"2008-10-30T14:06:16Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Samuel Tardieu wrote:\n>>>>>> \"Andreas\" == Andreas Ericsson writes:\n> \n> Andreas> This particular bikeshed was painted a long time ago, with\n> Andreas> the consensus going in favour of \"git push\" pushing all\n> Andreas> *matching* refspecs.\n> \n> I still don't understand why this is useful, especially when git push\n> already has a \"--all\" option.\n> \n\n--all pushes all refs, even the non-matching ones, which is very\nrarely desirable and only accidentally sometimes the same as \"push all\nmatching refs\".\n\n> I know that I've never had the intent to push all the refs without\n> thinking about it first. Most of the time, I intend to push only\n> the current branch I am in.\n> \n\nThen say so. There's a very simple command syntax for it:\n\"git push \"\n\n> The current behaviour made me remove the branches I was not actively\n> on locally, because I would get errors from \"git push\" all the time\n> saying that I was not up-to-date in those branches.\n> \n\nThat's an orthogonal issue, and one that really could be fixed without\nanyone complaining. Send a patch that checks if foo is a strict subset\nof /foo before trying to send it, and abort if it is so. This\nmeans that we'll try to push \"foo\" if upstream rewrote their \"foo\", but\nperhaps that's just as well.\n\nNote though that the patch mustn't try to apply any smarts if a ref is\ngiven explicitly.\n\n> Note that the \"git pull\" issue is completely different, as it merges\n> or fast forwards the current branch only.\n> \n\n\"git pull\" is actually only vaguely connected with \"git push\". The\nopposite of \"push\" is \"fetch\" in git lingo.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"94287","messageId":"2008-10-30-15-23-16+trackit+sam@rfc1149.net","threadId":"16081","inReplyTo":"4909BF58.9010500@op5.se","subject":"Re: Using the --track option when creating a branch","fromName":"Samuel Tardieu","fromEmail":"sam@rfc1149.net","sentAt":"2008-10-30T14:23:16Z","receivedAt":"2008-10-30T14:23:16Z","isPatch":false,"sender":{"key":"sam@rfc1149.net","avatar":"https://avatars.githubusercontent.com/u/44656?v=4"},"body":"* Andreas Ericsson [2008-10-30 15:06:16 +0100]\n\n> --all pushes all refs, even the non-matching ones, which is very\n> rarely desirable and only accidentally sometimes the same as \"push all\n> matching refs\".\n>\n>> I know that I've never had the intent to push all the refs without\n>> thinking about it first. Most of the time, I intend to push only\n>> the current branch I am in.\n>\n> Then say so. There's a very simple command syntax for it:\n> \"git push \"\n\nI update the branches I'm working in maybe 20 times a day, sometimes\nmore. When I make a change and all the tests pass, I prefer to call\n\n git push\n\nrather than\n\n git push origin 2.0-beta1\n\n(and \"2.0-beta1\" is a short name here, some branches have much longer\nnames)\n\nI think it would be better to have :\n\n git push <= push the current branch\n git push --all <= push all matching refs\n git push --all --create <= push all matching refs, create if needed\n\nThe latest command is probably used so rarely (compared to the others)\nthat it wouldn't be a problem to make it longer. Of course, if a\nrefspec is given explicitely, it should be honored and remote refs\ncreated if needed.\n\nI am curious of what other people workflows are. Do you often push\nmultiple branches at the same time? More often than one at a time?\nMany times a day?\n\n> \"git pull\" is actually only vaguely connected with \"git push\". The\n> opposite of \"push\" is \"fetch\" in git lingo.\n\nI know, but \"git fetch\" only updates remote tracking branches, and I\nthink that in the majority of the cases you want to advance all the\nremote references. And even if you screw up, the problem will only\nhappen in your local copy, not in an upstream or shared repository.\nI assume that most people \"push\" to public repositories and not\nmany of them \"pull\" into public repositories directly.\n"},{"id":"94290","messageId":"20081030144107.GE24098@artemis.corp","threadId":"16081","inReplyTo":"2008-10-30-15-23-16+trackit+sam@rfc1149.net","subject":"Re: Using the --track option when creating a branch","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-10-30T14:41:07Z","receivedAt":"2008-10-30T14:41:07Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Oct 30, 2008 at 02:23:16PM +0000, Samuel Tardieu wrote:\n> I think it would be better to have :\n> \n> git push <= push the current branch\n> git push --all <= push all matching refs\n> git push --all --create <= push all matching refs, create if needed\n> \n> The latest command is probably used so rarely (compared to the others)\n> that it wouldn't be a problem to make it longer. Of course, if a\n> refspec is given explicitely, it should be honored and remote refs\n> created if needed.\n\nFwiw I'm in favor of that, and it was what I advocated at the time.\n\nThough I think than as soon as you add an explicit remote name, like:\ngit push origin, pushing all matched references makes sense. Which is\nalso what I advocated at the time.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"94293","messageId":"4909CABD.1040708@op5.se","threadId":"16081","inReplyTo":"2008-10-30-15-23-16+trackit+sam@rfc1149.net","subject":"Re: Using the --track option when creating a branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-30T14:54:53Z","receivedAt":"2008-10-30T14:54:53Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Samuel Tardieu wrote:\n> * Andreas Ericsson [2008-10-30 15:06:16 +0100]\n> \n>> --all pushes all refs, even the non-matching ones, which is very\n>> rarely desirable and only accidentally sometimes the same as \"push all\n>> matching refs\".\n>>\n>>> I know that I've never had the intent to push all the refs without\n>>> thinking about it first. Most of the time, I intend to push only\n>>> the current branch I am in.\n>> Then say so. There's a very simple command syntax for it:\n>> \"git push \"\n> \n> I update the branches I'm working in maybe 20 times a day, sometimes\n> more. When I make a change and all the tests pass, I prefer to call\n> \n> git push\n> \n> rather than\n> \n> git push origin 2.0-beta1\n> \n\nSo why don't you? Unless you also make lots of changes on other branches,\nthe two commands will result in exactly the same thing.\n\n> (and \"2.0-beta1\" is a short name here, some branches have much longer\n> names)\n> \n> I think it would be better to have :\n> \n> git push <= push the current branch\n> git push --all <= push all matching refs\n> git push --all --create <= push all matching refs, create if needed\n> \n\nCorrect me if I'm wrong, but wouldn't my suggestion of not trying to\npush (even matching) branches that haven't been updated since we last\nfetched from the remote do exactly the same thing for your particular\nuse-case, but without syntax change and all the annoying minor parts\nthat it entails?\n\n\n> The latest command is probably used so rarely (compared to the others)\n> that it wouldn't be a problem to make it longer. Of course, if a\n> refspec is given explicitely, it should be honored and remote refs\n> created if needed.\n> \n> I am curious of what other people workflows are. Do you often push\n> multiple branches at the same time?\n\nQuite often, yes.\n\n> More often than one at a time?\n\nNo.\n\n> Many times a day?\n> \n\nDefine \"many\". Perhaps as often as 2-3 times per day. Not very often,\nbut frequent enough that I definitely want some short sweet way of\ndoing it. OTOH, I also find the \"rejected\" messages annoying, and I\ndefinitely feel one could do something about them. However, it's my\nbirthday today and I plan on being far too drunk/hungover the entire\nweekend for me to take any actions in that direction.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"94294","messageId":"2008-10-30-15-56-34+trackit+sam@rfc1149.net","threadId":"16081","inReplyTo":"20081030144107.GE24098@artemis.corp","subject":"Re: Using the --track option when creating a branch","fromName":"Samuel Tardieu","fromEmail":"sam@rfc1149.net","sentAt":"2008-10-30T14:56:34Z","receivedAt":"2008-10-30T14:56:34Z","isPatch":false,"sender":{"key":"sam@rfc1149.net","avatar":"https://avatars.githubusercontent.com/u/44656?v=4"},"body":"* Pierre Habouzit [2008-10-30 15:41:07 +0100]\n\n| On Thu, Oct 30, 2008 at 02:23:16PM +0000, Samuel Tardieu wrote:\n| > I think it would be better to have :\n| > \n| > git push <= push the current branch\n| > git push --all <= push all matching refs\n| > git push --all --create <= push all matching refs, create if needed\n| > \n| > The latest command is probably used so rarely (compared to the others)\n| > that it wouldn't be a problem to make it longer. Of course, if a\n| > refspec is given explicitely, it should be honored and remote refs\n| > created if needed.\n| \n| Fwiw I'm in favor of that, and it was what I advocated at the time.\n| \n| Though I think than as soon as you add an explicit remote name, like:\n| git push origin, pushing all matched references makes sense. Which is\n| also what I advocated at the time.\n\nIndeed, it makes sense. We could then have:\n\n git push <= push the current branch on default remote\n (which is, at least in my case, the most\n frequent use I want to make of \"git push\",\n on all the projects [work or volunteer]\n I work on)\n git push remote <= push all matching refs on named remote\n git push --all [remote] <= push and create all refs on remote (or default)\n\n Sam\n"},{"id":"94299","messageId":"2008-10-30-16-04-08+trackit+sam@rfc1149.net","threadId":"16081","inReplyTo":"4909CABD.1040708@op5.se","subject":"Re: Using the --track option when creating a branch","fromName":"Samuel Tardieu","fromEmail":"sam@rfc1149.net","sentAt":"2008-10-30T15:04:08Z","receivedAt":"2008-10-30T15:04:08Z","isPatch":false,"sender":{"key":"sam@rfc1149.net","avatar":"https://avatars.githubusercontent.com/u/44656?v=4"},"body":"* Andreas Ericsson [2008-10-30 15:54:53 +0100]\n\n> Correct me if I'm wrong, but wouldn't my suggestion of not trying to\n> push (even matching) branches that haven't been updated since we last\n> fetched from the remote do exactly the same thing for your particular\n> use-case, but without syntax change and all the annoying minor parts\n> that it entails?\n\nNot exactly. I often do some work on a branch which does not mandate\na topic branch and have to switch branches to fix a bug for example.\nThis would continue to push unterminated changes as well.\n\nTypical use case, which happens (to me) quite frequently:\n\n % git checkout master\n [start new feature, estimated implementation time 15 minutes]\n % git commit -m \"Reorganize foobar in previous of xyzzy.\"\n (note that I'm not sure that I will keep it, I'll know that later\n when my next commit is ready, maybe in 10 minutes, no need for\n a topic branch)\n [mail from a customer, \"I noticed some strange behaviour here\" --\n let's fix it]\n % git checkout 2.0-beta1-release-candidate\n [fix strange behaviour and add new test]\n [test locally]\n % git commit -m \"Fix strange behaviour baz.\"\n % git push\n (so that it goes to the buildfarm for QA testing)\n\nArgh, \"master\" has been pushed as well. Ok, I could have done\n\n % git branch\n (because I know I am on the right branch but do not necessarily\n remember its full name all the time)\n % git push origin 2.0-beta1-release-candidate\n\nor I could have started a topic branch, but I often push 2 or 3\ncommits at a time instead, the first one being a refactoring of\nexisting code to ease the subsequent one.\n\n>From what I have seen, people I am working with often have the\nsame workflow (do not systematically start a topic branch when\nin active development mode)\n\n> Define \"many\". Perhaps as often as 2-3 times per day. Not very often,\n> but frequent enough that I definitely want some short sweet way of\n> doing it. OTOH, I also find the \"rejected\" messages annoying, and I\n> definitely feel one could do something about them. However, it's my\n> birthday today and I plan on being far too drunk/hungover the entire\n> weekend for me to take any actions in that direction.\n\nHappy birthday :)\n"},{"id":"94304","messageId":"4909D1FE.2080403@op5.se","threadId":"16081","inReplyTo":"2008-10-30-16-04-08+trackit+sam@rfc1149.net","subject":"Re: Using the --track option when creating a branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-30T15:25:50Z","receivedAt":"2008-10-30T15:25:50Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Samuel Tardieu wrote:\n> * Andreas Ericsson [2008-10-30 15:54:53 +0100]\n> \n>> Correct me if I'm wrong, but wouldn't my suggestion of not trying to\n>> push (even matching) branches that haven't been updated since we last\n>> fetched from the remote do exactly the same thing for your particular\n>> use-case, but without syntax change and all the annoying minor parts\n>> that it entails?\n> \n> Not exactly. I often do some work on a branch which does not mandate\n> a topic branch and have to switch branches to fix a bug for example.\n> This would continue to push unterminated changes as well.\n> \n> Typical use case, which happens (to me) quite frequently:\n> \n\n...\n\n>\n> Argh, \"master\" has been pushed as well. Ok, I could have done\n> \n\nAh, I see. I sympathize, although I really do think you'd be\nbetter off by learning to explicitly push things.\n\n> % git branch\n> (because I know I am on the right branch but do not necessarily\n> remember its full name all the time)\n\nofftopic: Use shell-completion and set your PS1 to include the __git_ps1\noutput.\n\n> % git push origin 2.0-beta1-release-candidate\n> \n> or I could have started a topic branch, but I often push 2 or 3\n> commits at a time instead, the first one being a refactoring of\n> existing code to ease the subsequent one.\n> \n\nI fail to see why this would prevent you from starting a topic-branch.\nIn fact, I would have thought it was a reason *for* starting a topic.\n\n>>From what I have seen, people I am working with often have the\n> same workflow (do not systematically start a topic branch when\n> in active development mode)\n> \n>> Define \"many\". Perhaps as often as 2-3 times per day. Not very often,\n>> but frequent enough that I definitely want some short sweet way of\n>> doing it. OTOH, I also find the \"rejected\" messages annoying, and I\n>> definitely feel one could do something about them. However, it's my\n>> birthday today and I plan on being far too drunk/hungover the entire\n>> weekend for me to take any actions in that direction.\n> \n> Happy birthday :)\n> \n\nThank you :-)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"94306","messageId":"18697.54743.601331.133842@lisa.zopyra.com","threadId":"16081","inReplyTo":"4909D1FE.2080403@op5.se","subject":"Re: Using the --track option when creating a branch","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2008-10-30T15:42:15Z","receivedAt":"2008-10-30T15:42:15Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Thursday, October 30, 2008 at 16:25:50 (+0100) Andreas Ericsson writes:\n>Samuel Tardieu wrote:\n>> * Andreas Ericsson [2008-10-30 15:54:53 +0100]\n>> \n>>> Correct me if I'm wrong, but wouldn't my suggestion of not trying to\n>>> push (even matching) branches that haven't been updated since we last\n>>> fetched from the remote do exactly the same thing for your particular\n>>> use-case, but without syntax change and all the annoying minor parts\n>>> that it entails?\n>> \n>> Not exactly. I often do some work on a branch which does not mandate\n>> a topic branch and have to switch branches to fix a bug for example.\n>> This would continue to push unterminated changes as well.\n>> \n>> Typical use case, which happens (to me) quite frequently:\n>> \n>\n>...\n>\n>>\n>> Argh, \"master\" has been pushed as well. Ok, I could have done\n>> \n>\n>Ah, I see. I sympathize, although I really do think you'd be\n>better off by learning to explicitly push things.\n\nExactly my concerns when I raised this issue originally. It's hard to\nteach people to do this:\n\n% git push origin master\n\nor:\n\n% git pull origin master\n\nso that when they intend and MUST do this (lest chaos ensue):\n\n% git push origin ReleaseBranch\n\nor this:\n\n% git pull origin ReleaseBranch\n\nthey don't mistakenly do this:\n\n% git push\n\nor:\n\n% git pull\n\nthe reason being that every manual our users read says \"use git push\",\nuse \"git pull\", the examples being written for 'master' branch usage,\nand people just assume that 'git push'/'git pull' are smart enough to\nknow which branch you are on and do the same logical thing as a bare\n'git push'/'git pull' does when on master.\n\nSeveral times this has happened to us: people make this mistake and\npush or pull stuff into a branch they do not want. The pull is not so\nbad, but the push messes up our central repo. This has happened both\nhere at my current company, and my previous one, and the persons\nmaking the mistakes are neither sloppy nor inexperienced.\n\n\nBill\n"},{"id":"94314","messageId":"1225385081.19891.1.camel@maia.lan","threadId":"16081","inReplyTo":"4909A7C4.30507@op5.se","subject":"Re: Using the --track option when creating a branch","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-30T16:44:41Z","receivedAt":"2008-10-30T16:44:41Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Thu, 2008-10-30 at 13:25 +0100, Andreas Ericsson wrote:\n> >> Ok, now I'm confused. The ONLY thing I want to prevent is the\n> >> \"crossing of streams\" issue. If I am on branch X and issue 'git\n> >> push', I want X, and ONLY X, to be pushed to the remote repository's X\n> >> branch --- I don't care if other branches are pushed to their\n> >> respective remote branches, as long as they don't get merged to X.\n> This particular bikeshed was painted a long time ago, with the consensus\n> going in favour of \"git push\" pushing all *matching* refspecs.\n\nI realise that - I just found it interesting that there was a user who\nexplicitly expected this not to be the case.\n\nWhich I think is reasonable, because it's what 'git pull' does. I\nmyself have encountered many people who did not like the current default\nbehaviour. I think far from \"bikeshedding\" this is quite an important\npart of the ui experience.\n\nSam.\n"},{"id":"94328","messageId":"1225389460.19891.31.camel@maia.lan","threadId":"16081","inReplyTo":"4909CABD.1040708@op5.se","subject":"Re: Using the --track option when creating a branch","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-30T17:57:40Z","receivedAt":"2008-10-30T17:57:40Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Thu, 2008-10-30 at 15:54 +0100, Andreas Ericsson wrote:\n> > I am curious of what other people workflows are. Do you often push\n> > multiple branches at the same time?\n> \n> Quite often, yes.\n> \n> > More often than one at a time?\n> \n> No.\n> \n> > Many times a day?\n> > \n> \n> Define \"many\". Perhaps as often as 2-3 times per day. Not very often,\n> but frequent enough that I definitely want some short sweet way of\n> doing it.\n\nI think your use case is the unusual one, not the common one. Most\nusers will want the moral equivalent of \"push = HEAD\" by default, and\nthose who prefer the existing behaviour can configure it.\n\nSam.\n"},{"id":"94329","messageId":"1225389626.19891.35.camel@maia.lan","threadId":"16081","inReplyTo":"2008-10-30-15-56-34+trackit+sam@rfc1149.net","subject":"Re: Using the --track option when creating a branch","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-30T18:00:26Z","receivedAt":"2008-10-30T18:00:26Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Thu, 2008-10-30 at 15:56 +0100, Samuel Tardieu wrote:\n> * Pierre Habouzit [2008-10-30 15:41:07 +0100]\n> \n> | On Thu, Oct 30, 2008 at 02:23:16PM +0000, Samuel Tardieu wrote:\n> | > I think it would be better to have :\n> | > \n> | > git push <= push the current branch\n> | > git push --all <= push all matching refs\n> | > git push --all --create <= push all matching refs, create if needed\n> | > \n> | > The latest command is probably used so rarely (compared to the others)\n> | > that it wouldn't be a problem to make it longer. Of course, if a\n> | > refspec is given explicitely, it should be honored and remote refs\n> | > created if needed.\n> | \n> | Fwiw I'm in favor of that, and it was what I advocated at the time.\n> | \n> | Though I think than as soon as you add an explicit remote name, like:\n> | git push origin, pushing all matched references makes sense. Which is\n> | also what I advocated at the time.\n> \n> Indeed, it makes sense. We could then have:\n> \n> git push <= push the current branch on default remote\n> (which is, at least in my case, the most\n> frequent use I want to make of \"git push\",\n> on all the projects [work or volunteer]\n> I work on)\n\n\n> git push remote <= push all matching refs on named remote\n\nI think that 'git push origin' should be the same as 'git push'; so,\n'git push remote' would then just push the current head to the tracking\nbranch of that remote. This exposes another issue with the current\nmethod of configuring the tracking branch, which is that only one remote\nand branch may be configured for each local branch. In reality, someone\nmight be pushing and pulling from multiple remotes; expecting them to\nkeep naming the current branch all the time seems arduous. \n\nI think if you want matching refs to be pushed, say so:\n\n git push remote --matching\n\n> git push --all [remote] <= push and create all refs on remote (or default)\n"},{"id":"94337","messageId":"490A0770.5060600@xiplink.com","threadId":"16081","inReplyTo":"18697.54743.601331.133842@lisa.zopyra.com","subject":"Re: Using the --track option when creating a branch","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-30T19:13:52Z","receivedAt":"2008-10-30T19:13:52Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Bill Lear wrote:\n> \n> the reason being that every manual our users read says \"use git push\",\n> use \"git pull\", the examples being written for 'master' branch usage,\n> and people just assume that 'git push'/'git pull' are smart enough to\n> know which branch you are on and do the same logical thing as a bare\n> 'git push'/'git pull' does when on master.\n\nI agree that this is a 'gotcha' for git-push. I'm a new git user, and \nI've been experimenting with git and reading the documentation for the \nlast few weeks. But I would not have known about this behavior if it \nweren't for this thread.\n\nYes, push's man page is clear about what happens if you push with no \nrefspec, and the fetch & pull man pages both have an obscure note to \n\"never do your own development on branches that appear\non the right hand side of a colon on 'Pull:' lines\". But \nstill the behavior is not what I expected. Before I read this thread, I \nmissed the implications of what those parts of the man pages were saying.\n\nOne could call this a failure of the documentation (man pages and \nbeyond). Personally, though, I tend to expect minimal commands to do \nminimal things. So a plain \"git push\" would do the minimum amount of \npushing, and if I want it to do more I'd add extra parameters to the \ncommand.\n\nThe current behavior seems fairly harmless if you always follow the \npattern of creating topic branches for all your work. But git (rightly) \ndoesn't enforce that pattern, and so I think push shouldn't default to \ndoing something potentially harmful just because you forgot to create a \ntopic branch one day. (Or maybe you decided to be clever and give one \nof your local branches the same name as a remote's branch...)\n\n\t\tMarc\n"},{"id":"94348","messageId":"gedfmt$q9c$1@ger.gmane.org","threadId":"16081","inReplyTo":"2008-10-30-15-23-16+trackit+sam@rfc1149.net","subject":"Re: Using the --track option when creating a branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-30T23:24:12Z","receivedAt":"2008-10-30T23:24:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: Samuel Tardieu , Andreas Ericsson ,\n git@vger.kernel.org]\n\nSamuel Tardieu wrote:\n> * Andreas Ericsson [2008-10-30 15:06:16 +0100]\n> \n>> --all pushes all refs, even the non-matching ones, which is very\n>> rarely desirable and only accidentally sometimes the same as \"push all\n>> matching refs\".\n>>\n>>> I know that I've never had the intent to push all the refs without\n>>> thinking about it first. Most of the time, I intend to push only\n>>> the current branch I am in.\n>>\n>> Then say so. There's a very simple command syntax for it:\n>> \"git push \"\n> \n> I update the branches I'm working in maybe 20 times a day, sometimes\n> more. When I make a change and all the tests pass, I prefer to call\n> \n> git push\n> \n> rather than\n> \n> git push origin 2.0-beta1\n> \n> (and \"2.0-beta1\" is a short name here, some branches have much longer\n> names)\n\nYou can use\n\n $ git push origin HEAD\n\nand I think (but I am not sure) that there is DWIM-mery allowing\nto simply say\n\n $ git push HEAD\n\nand it would use configured branch.$(git symbolic-ref HEAD).remote\n\n\nAnd if it is not as I said, the patches would better made it so, instead of\nchanging default behavior from push matching refspecs to push current\nbranch only.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"94624","messageId":"20081102042359.GC5261@coredump.intra.peff.net","threadId":"16081","inReplyTo":"2008-10-30-14-52-52+trackit+sam@rfc1149.net","subject":"Re: Using the --track option when creating a branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-02T04:23:59Z","receivedAt":"2008-11-02T04:23:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 30, 2008 at 02:52:52PM +0100, Samuel Tardieu wrote:\n\n> The current behaviour made me remove the branches I was not actively\n> on locally, because I would get errors from \"git push\" all the time\n> saying that I was not up-to-date in those branches.\n\nNot triggering an error on these branches has been discussed a few times\nbefore, but I'm not sure we ever reached a conclusion of what the ideal\nbehavior would be.\n\nTry this thread:\n\n http://thread.gmane.org/gmane.comp.version-control.git/85469\n\nwhich points to a few others. Comments welcome.\n\n-Peff\n"}]}