{"thread":{"id":"30956","subject":"[PATCH] branch: make --set-upstream saner without an explicit starting point","startedAt":"2012-07-05T09:29:49Z","lastAt":"2012-08-16T21:58:55Z","messageCount":11,"participants":["Carlos Martín Nieto","Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"194649","messageId":"1341480589-1890-1-git-send-email-cmn@elego.de","threadId":"30956","inReplyTo":null,"subject":"[PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-05T09:29:49Z","receivedAt":"2012-07-05T09:29:49Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"The branch command assumes HEAD as the starting point if none is\nspecified. This causes --set-upstream to behave unexpectedly if the\nuser types\n\n git branch --set-upstream origin/master\n\ngit-branch will assume a second argument of HEAD and create config\nentries for a local branch origin/master to track the current\nbranch. This is rarely, if ever, what the user wants to do.\n\nCatch invocations with --set-upstream and only one branch so the\ncommand above sets up the current branch to track origin's master\nbranch.\n\nSigned-off-by: Carlos Martín Nieto \n---\n\nI got tired of --set-upstream biting me in the arse so I (presumably)\nfixed it. I've only run the t3200 test for now. I'll check the rest of\nthe suite when I'm in front of a computer that's got some power, but I\ndon't expect other tests to be affected.\n\n builtin/branch.c | 16 ++++++++++++++--\n t/t3200-branch.sh | 23 +++++++++++++++++++++++\n 2 files changed, 37 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 0e060f2..6bbabda 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -853,10 +853,22 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\telse\n \t\t\tusage_with_options(builtin_branch_usage, options);\n \t} else if (argc > 0 && argc <= 2) {\n+\t\tconst char *branch, *upstream;\n \t\tif (kinds != REF_LOCAL_BRANCH)\n \t\t\tdie(_(\"-a and -r options to 'git branch' do not make sense with a branch name\"));\n-\t\tcreate_branch(head, argv[0], (argc == 2) ? argv[1] : head,\n-\t\t\t force_create, reflog, 0, quiet, track);\n+\n+\t\t/* The usual way, make the branch point be HEAD of none is specified */\n+\t\tbranch = argv[0];\n+\t\tupstream = (argc == 2) ? argv[1] : head;\n+\n+\t\t/* If the command was 'git branch --set-upstream origin/master',\n+\t\t make HEAD track origin/master, not the other way around */\n+\t\tif (track == BRANCH_TRACK_OVERRIDE && argc == 1) {\n+\t\t\tbranch = head;\n+\t\t\tupstream = argv[0];\n+\t\t}\n+\n+\t\tcreate_branch(head, branch, upstream, force_create, reflog, 0, quiet, track);\n \t} else\n \t\tusage_with_options(builtin_branch_usage, options);\n \ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex a17f8b2..e06d642 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -369,6 +369,29 @@ test_expect_success \\\n 'git tag foobar &&\n test_must_fail git branch --track my11 foobar'\n \n+test_expect_success 'set upstream with both branches explicit' \\\n+ 'git config remote.local.url . &&\n+ git config remote.local.fetch refs/heads/master:refs/remotes/local/master &&\n+ (git show-ref -q refs/remotes/local/master || git fetch local) &&\n+ git branch --no-track my12 &&\n+ git branch --set-upstream my12 local/master &&\n+ test $(git config branch.my12.remote) = local &&\n+ test $(git config branch.my12.merge) = refs/heads/master'\n+\n+# The unsets at the end is to leave the master config as we found it,\n+# so later tests don't get confused\n+\n+test_expect_success 'set upstream with implicit HEAD as branch to modify' \\\n+ 'git config remote.local.url . &&\n+ git config remote.local.fetch refs/heads/master:refs/remotes/local/master &&\n+ (git show-ref -q refs/remotes/local/master || git fetch local) &&\n+ git branch --set-upstream local/master &&\n+ test $(git config branch.master.remote) = local &&\n+ test $(git config branch.master.merge) = refs/heads/master\n+ git config --unset branch.master.remote &&\n+ git config --unset branch.master.merge\n+'\n+\n # Keep this test last, as it changes the current branch\n cat >expect < 1117150200 +0000\tbranch: Created from master\n-- \n1.7.11.1.104.ge7b44f1\n"},{"id":"194650","messageId":"20120705094213.GA29740@sigill.intra.peff.net","threadId":"30956","inReplyTo":"1341480589-1890-1-git-send-email-cmn@elego.de","subject":"Re: [PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-07-05T09:42:13Z","receivedAt":"2012-07-05T09:42:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jul 05, 2012 at 11:29:49AM +0200, Carlos Martín Nieto wrote:\n\n> The branch command assumes HEAD as the starting point if none is\n> specified. This causes --set-upstream to behave unexpectedly if the\n> user types\n> \n> git branch --set-upstream origin/master\n> \n> git-branch will assume a second argument of HEAD and create config\n> entries for a local branch origin/master to track the current\n> branch. This is rarely, if ever, what the user wants to do.\n> \n> Catch invocations with --set-upstream and only one branch so the\n> command above sets up the current branch to track origin's master\n> branch.\n\nI have been tempted to write this patch several times but was afraid\nthat somebody was relying on the existing behavior. I think the behavior\nyou propose is much saner.\n\n> +# The unsets at the end is to leave the master config as we found it,\n> +# so later tests don't get confused\n> +\n> +test_expect_success 'set upstream with implicit HEAD as branch to modify' \\\n> + 'git config remote.local.url . &&\n> + git config remote.local.fetch refs/heads/master:refs/remotes/local/master &&\n> + (git show-ref -q refs/remotes/local/master || git fetch local) &&\n> + git branch --set-upstream local/master &&\n> + test $(git config branch.master.remote) = local &&\n> + test $(git config branch.master.merge) = refs/heads/master\n> + git config --unset branch.master.remote &&\n> + git config --unset branch.master.merge\n> +'\n\nThe unsets will not run if the test fails. Use test_when_finished to\ninsert cleanup, or better yet use test_config which handles this case\nautomagically (you are not setting them initially, but perhaps you\nshould set them to some known value initially to make sure that your\ncommand changes them as expected).\n\nI don't understand the point of the show-ref call, though. Isn't the\nfetch idempotent, and you can just run it always?\n\n-Peff\n"},{"id":"194657","messageId":"1341506065.10752.19.camel@flaca.cmartin.tk","threadId":"30956","inReplyTo":"20120705094213.GA29740@sigill.intra.peff.net","subject":"Re: [PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-05T16:34:25Z","receivedAt":"2012-07-05T16:34:25Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Thu, 2012-07-05 at 05:42 -0400, Jeff King wrote:\n> On Thu, Jul 05, 2012 at 11:29:49AM +0200, Carlos Martín Nieto wrote:\n> \n> > The branch command assumes HEAD as the starting point if none is\n> > specified. This causes --set-upstream to behave unexpectedly if the\n> > user types\n> > \n> > git branch --set-upstream origin/master\n> > \n> > git-branch will assume a second argument of HEAD and create config\n> > entries for a local branch origin/master to track the current\n> > branch. This is rarely, if ever, what the user wants to do.\n> > \n> > Catch invocations with --set-upstream and only one branch so the\n> > command above sets up the current branch to track origin's master\n> > branch.\n> \n> I have been tempted to write this patch several times but was afraid\n> that somebody was relying on the existing behavior. I think the behavior\n> you propose is much saner.\n\nThose two people who rely on the current behaviour will just have to\nmake a sacrifice for the good of the rest of the user community. I guess\nwe could introduce it in steps by first warning, but I doubt it would be\nworth the effort.\n\n> \n> > +# The unsets at the end is to leave the master config as we found it,\n> > +# so later tests don't get confused\n> > +\n> > +test_expect_success 'set upstream with implicit HEAD as branch to modify' \\\n> > + 'git config remote.local.url . &&\n> > + git config remote.local.fetch refs/heads/master:refs/remotes/local/master &&\n> > + (git show-ref -q refs/remotes/local/master || git fetch local) &&\n> > + git branch --set-upstream local/master &&\n> > + test $(git config branch.master.remote) = local &&\n> > + test $(git config branch.master.merge) = refs/heads/master\n> > + git config --unset branch.master.remote &&\n> > + git config --unset branch.master.merge\n> > +'\n> \n> The unsets will not run if the test fails. Use test_when_finished to\n> insert cleanup, or better yet use test_config which handles this case\n> automagically (you are not setting them initially, but perhaps you\n> should set them to some known value initially to make sure that your\n> command changes them as expected).\n\nConsidering that the unset is there only because a later test does 'git\nfetch' instead of specifying which remote we should fetch from, and this\nsetting confuses it (expecting to fetch from origin, but instead\nfetching from local), I wonder if it wouldn't be better to simply make\nthe fetch explicit in line 712 so it reads 'git fetch origin'. This way\nwe can forget about undoing the configuration, because we're overriding\nit anyway.\n> \n> I don't understand the point of the show-ref call, though. Isn't the\n> fetch idempotent, and you can just run it always?\n\nThat is a good point. I just copied what the --track tests are doing a\nfew tests up. Looking at more tests, it seems to be what most do. Maybe\nsomething like this:\n\n---8<---\n\nSubject: branch: make --set-upstream saner without an explicit\n starting point\n\nThe branch command assumes HEAD as the starting point if none is\nspecified. This causes --set-upstream to behave unexpectedly if the\nuser types\n\n git branch --set-upstream origin/master\n\ngit-branch will assume a second argument of HEAD and create config\nentries for a local branch origin/master to track the current\nbranch. This is rarely, if ever, what the user wants to do.\n\nCatch invocations with --set-upstream and only one branch so the\ncommand above sets up the current branch to track origin's master\nbranch.\n\nSigned-off-by: Carlos Martín Nieto \n---\n builtin/branch.c | 16 ++++++++++++++--\n t/t3200-branch.sh | 20 +++++++++++++++++++-\n 2 files changed, 33 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 0e060f2..6bbabda 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -853,10 +853,22 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\telse\n \t\t\tusage_with_options(builtin_branch_usage, options);\n \t} else if (argc > 0 && argc <= 2) {\n+\t\tconst char *branch, *upstream;\n \t\tif (kinds != REF_LOCAL_BRANCH)\n \t\t\tdie(_(\"-a and -r options to 'git branch' do not make sense with a branch name\"));\n-\t\tcreate_branch(head, argv[0], (argc == 2) ? argv[1] : head,\n-\t\t\t force_create, reflog, 0, quiet, track);\n+\n+\t\t/* The usual way, make the branch point be HEAD of none is specified */\n+\t\tbranch = argv[0];\n+\t\tupstream = (argc == 2) ? argv[1] : head;\n+\n+\t\t/* If the command was 'git branch --set-upstream origin/master',\n+\t\t make HEAD track origin/master, not the other way around */\n+\t\tif (track == BRANCH_TRACK_OVERRIDE && argc == 1) {\n+\t\t\tbranch = head;\n+\t\t\tupstream = argv[0];\n+\t\t}\n+\n+\t\tcreate_branch(head, branch, upstream, force_create, reflog, 0, quiet, track);\n \t} else\n \t\tusage_with_options(builtin_branch_usage, options);\n \ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex a17f8b2..1b0a73c 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -369,6 +369,24 @@ test_expect_success \\\n 'git tag foobar &&\n test_must_fail git branch --track my11 foobar'\n \n+test_expect_success 'set upstream with both branches explicit' \\\n+ 'git config remote.local.url . &&\n+ git config remote.local.fetch refs/heads/master:refs/remotes/local/master &&\n+ git fetch local &&\n+ git branch --no-track my12 &&\n+ git branch --set-upstream my12 local/master &&\n+ test $(git config branch.my12.remote) = local &&\n+ test $(git config branch.my12.merge) = refs/heads/master'\n+\n+test_expect_success 'set upstream with implicit HEAD as branch to modify' \\\n+ 'git config remote.local.url . &&\n+ git config remote.local.fetch refs/heads/master:refs/remotes/local/master &&\n+ git fetch local &&\n+ git branch --set-upstream local/master &&\n+ test $(git config branch.master.remote) = local &&\n+ test $(git config branch.master.merge) = refs/heads/master\n+'\n+\n # Keep this test last, as it changes the current branch\n cat >expect < 1117150200 +0000\tbranch: Created from master\n@@ -686,7 +704,7 @@ test_expect_success 'use set-upstream on the current branch' '\n \tgit --bare init myupstream.git &&\n \tgit push myupstream.git master:refs/heads/frotz &&\n \tgit remote add origin myupstream.git &&\n-\tgit fetch &&\n+\tgit fetch origin &&\n \tgit branch --set-upstream master origin/frotz &&\n \n \ttest \"z$(git config branch.master.remote)\" = \"zorigin\" &&\n-- \n1.7.11.1.104.ge7b44f1\n"},{"id":"194659","messageId":"7vd34arvhu.fsf@alter.siamese.dyndns.org","threadId":"30956","inReplyTo":"1341480589-1890-1-git-send-email-cmn@elego.de","subject":"Re: [PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-05T17:03:09Z","receivedAt":"2012-07-05T17:03:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto writes:\n\n> The branch command assumes HEAD as the starting point if none is\n> specified. This causes --set-upstream to behave unexpectedly if the\n> user types\n>\n> git branch --set-upstream origin/master\n>\n> git-branch will assume a second argument of HEAD and create config\n> entries for a local branch origin/master to track the current\n> branch. This is rarely, if ever, what the user wants to do.\n>\n> Catch invocations with --set-upstream and only one branch so the\n> command above sets up the current branch to track origin's master\n> branch.\n\nIf you look at the set of management operations \"git branch\"\n(i.e. other than \"listing\" [*1*]) allows you to do, the first name\non the command line always is the branch that is manipulated for\neverything other than the \"set upstream\" operation. In that sense,\nthe current implementation consistently handles command line\narguments with other options, and your patch breaks the consistency\nin the UI.\n\nI think it was a mistake that nobody noticed that it is likely that\nthe operation most often will be done for the current branch and the\nusual \"give me one branch name to operate on, or I'll operate on the\ncurrent branch\" command line convention of \"git branch\" commannd is\nnot a good fit for it, when \"set upstream\" feature was added, and\nsuggested an alternative syntax that avoids the mistake you quoted\nabove, perhaps something like:\n\n\tgit branch --set-upstream-to=origin/master [HEAD]\n\nwhich would have been very clear whose upstream is set to what (with\nor without the name of the other branch). In other words, make the\nname \"origin/master\" *NOT* the first branch name on the command line\nin the usual sense, but a parameter to the --set-upstream option, so\nthat \"give me one branch name to operate on, or I'll operate on the\ncurrent branch\" convention is still kept.\n\nYou also broke people who corrected another kind of mistake in this\nworkflow:\n\n git checkout frotz\n hack hack\n # ok, shared infrastructure between two branches are\n # sound, and I can build the other topic on top of this\n # state\n git branch nitfol\n # oops, forgot to mark that nitfol is derived on frotz with --track\n git branch --set-upstream nitfol\n\nwhere the last one meant \"git branch --set-upstream nitfol frotz\",\nto retroactively mark the upstream of the named branch, no?\n\nEven though my instinct tends to agree with your \"is rarely, if\never\", I do not think it is sane to change the behaviour of a\ncommand that produced one result without failing to produce\nsomething entirely different like your patch does (it would have\nbeen a different story if an operation that everybody got failure\nand did not produce a useful result were updated to produce a useful\nresult).\n\nComing from the above observation, while I am sympathetic to your\ncause and agree that we would want to do something about it, I am\nhaving a hard time to convince myself that your patch is the best\nway to go.\n\nI am not entirely happy with the hypothetical \"set-upstream-to\"\nmyself, either.\n\n\n[Footnote]\n\n*1* The point of \"listing\" is you do not know the names and asking\nthe command to produce them, so it is OK to be different. The \"set\nupstream\" operation in question does not share the excuse to be\ndifferent.\n"},{"id":"194664","messageId":"7vtxxmqezp.fsf@alter.siamese.dyndns.org","threadId":"30956","inReplyTo":"7vd34arvhu.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-05T17:44:58Z","receivedAt":"2012-07-05T17:44:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I think it was a mistake that nobody noticed that it is likely that\n> the operation most often will be done for the current branch and the\n> usual \"give me one branch name to operate on, or I'll operate on the\n> current branch\" command line convention of \"git branch\" commannd is\n> not a good fit for it, when \"set upstream\" feature was added, and\n> suggested an alternative syntax that avoids the mistake you quoted\n> above, perhaps something like:\n>\n> \tgit branch --set-upstream-to=origin/master [HEAD]\n>\n> which would have been very clear whose upstream is set to what (with\n> or without the name of the other branch). In other words, make the\n> name \"origin/master\" *NOT* the first branch name on the command line\n> in the usual sense, but a parameter to the --set-upstream option, so\n> that \"give me one branch name to operate on, or I'll operate on the\n> current branch\" convention is still kept.\n> \n> You also broke people who corrected another kind of mistake in this\n> workflow:\n> ...\n> Coming from the above observation, while I am sympathetic to your\n> cause and agree that we would want to do something about it, I am\n> having a hard time to convince myself that your patch is the best\n> way to go.\n>\n> I am not entirely happy with the hypothetical \"set-upstream-to\"\n> myself, either.\n\nThinking about it a bit more, I am starting to think that something\nbased on the \"set upstream to\" could be a sane way forward:\n\n * add \"git branch [--set-upstream-to=]\" that does what your\n patch does. The synopsis must make it clear that is not\n the usual first like other \"branch\" command line arguments\n that specify the branch being operated on, but is an argument to\n the --set-upstream option [*1*].\n\n * when \"git branch --set-upstream \" without \n is given, you first see if exists and find out the\n upstream of , do what the user told you to do (i.e. reset\n the upstream of the d branch to the current branch), and\n give hints to recover. Two possibilities:\n\n $ git checkout frotz\n $ git branch --set-upstream xyzzy\n Branch xyzzy set up to track local branch frotz.\n If you wanted to make frotz track xyzzy, do this:\n $ git branch --set-upstream xyzzy \n $ git branch --set-upstream-to xyzzy\n\n $ git checkout frotz\n $ git branch --set-upstream origin/xyzzy\n Branch origin/xyzzy set up to track local branch frotz.\n If you wanted to make frotz track xyzzy, do this:\n $ git branch -d origin/xyzzy\n $ git branch --set-upstream-to origin/xyzzy\n\n * possibly, deprecate --set-upstream as a historical wart that had\n misdesigned UI, and when it is used, give deprecation warning and\n nudge the user to use --set-upstream-to instead.\n\n\n[Footnote]\n\n*1* The parseopt parser will allow both of:\n\n $ git branch --set-upstream-to=origin/master\n $ git branch --set-upstream-to origin/master\n\n but the braket around the option name \"--set-upstream-to\" and\n its argument should make it clear, i.e.\n\n\tgit branch [--set-upstream-to ] []\n\n or\n\n \tgit branch [--set-upstream-to=] []\n"},{"id":"194695","messageId":"1341559103.10752.59.camel@flaca.cmartin.tk","threadId":"30956","inReplyTo":"7vtxxmqezp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-06T07:18:23Z","receivedAt":"2012-07-06T07:18:23Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Thu, 2012-07-05 at 10:44 -0700, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > I think it was a mistake that nobody noticed that it is likely that\n> > the operation most often will be done for the current branch and the\n> > usual \"give me one branch name to operate on, or I'll operate on the\n> > current branch\" command line convention of \"git branch\" commannd is\n> > not a good fit for it, when \"set upstream\" feature was added, and\n> > suggested an alternative syntax that avoids the mistake you quoted\n> > above, perhaps something like:\n> >\n> > \tgit branch --set-upstream-to=origin/master [HEAD]\n> >\n> > which would have been very clear whose upstream is set to what (with\n> > or without the name of the other branch). In other words, make the\n> > name \"origin/master\" *NOT* the first branch name on the command line\n> > in the usual sense, but a parameter to the --set-upstream option, so\n> > that \"give me one branch name to operate on, or I'll operate on the\n> > current branch\" convention is still kept.\n> > \n> > You also broke people who corrected another kind of mistake in this\n> > workflow:\n> > ...\n> > Coming from the above observation, while I am sympathetic to your\n> > cause and agree that we would want to do something about it, I am\n> > having a hard time to convince myself that your patch is the best\n> > way to go.\n> >\n> > I am not entirely happy with the hypothetical \"set-upstream-to\"\n> > myself, either.\n>\n> Thinking about it a bit more, I am starting to think that something\n> based on the \"set upstream to\" could be a sane way forward:\n> \n> * add \"git branch [--set-upstream-to=]\" that does what your\n> patch does. The synopsis must make it clear that is not\n> the usual first like other \"branch\" command line arguments\n> that specify the branch being operated on, but is an argument to\n> the --set-upstream option [*1*].\n\nLet's do this then. Disregard my earlier patch making -u a synonym of\n--set-upstream so we can make it a synonym of --set-upstream-to instead.\nThis way we can use -u and then it's not so bad if the long name is a\nbit ugly.\n\n> \n> * when \"git branch --set-upstream \" without \n> is given, you first see if exists and find out the\n> upstream of , do what the user told you to do (i.e. reset\n> the upstream of the d branch to the current branch), and\n> give hints to recover. Two possibilities:\n> \n> $ git checkout frotz\n> $ git branch --set-upstream xyzzy\n> Branch xyzzy set up to track local branch frotz.\n> If you wanted to make frotz track xyzzy, do this:\n> $ git branch --set-upstream xyzzy \n> $ git branch --set-upstream-to xyzzy\n> \n> $ git checkout frotz\n> $ git branch --set-upstream origin/xyzzy\n> Branch origin/xyzzy set up to track local branch frotz.\n> If you wanted to make frotz track xyzzy, do this:\n> $ git branch -d origin/xyzzy\n> $ git branch --set-upstream-to origin/xyzzy\n\nYep, this seems good. Now that you mention the existing, I wonder\nif letting --set-upstream create the branch as well wasn't another bad\ndecision, as the name suggests it's for setting that information after\nthe branch has already been created.\n\n> \n> * possibly, deprecate --set-upstream as a historical wart that had\n> misdesigned UI, and when it is used, give deprecation warning and\n> nudge the user to use --set-upstream-to instead.\n\nI'd definitely like to deprecate the current behaviour. It's a common\nsource of irritation (not just for me personally, it shows up in #git\nevery once in a while).\n\nI'll probably have some patches to send at the end of the weekend.\n\n cmn\n"},{"id":"194696","messageId":"7vpq89ny8q.fsf@alter.siamese.dyndns.org","threadId":"30956","inReplyTo":"1341559103.10752.59.camel@flaca.cmartin.tk","subject":"Re: [PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-06T07:29:41Z","receivedAt":"2012-07-06T07:29:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto writes:\n\n> Yep, this seems good. Now that you mention the existing, I wonder\n> if letting --set-upstream create the branch as well wasn't another bad\n> decision, as the name suggests it's for setting that information after\n> the branch has already been created.\n\nYou should be able to correct that for --set-upstream-to=.\nIt is clearly about setting upstream for an existing branch, right?\n"},{"id":"194699","messageId":"1341561809.10752.61.camel@flaca.cmartin.tk","threadId":"30956","inReplyTo":"7vpq89ny8q.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-06T08:03:29Z","receivedAt":"2012-07-06T08:03:29Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Fri, 2012-07-06 at 00:29 -0700, Junio C Hamano wrote:\n> Carlos Martín Nieto writes:\n> \n> > Yep, this seems good. Now that you mention the existing, I wonder\n> > if letting --set-upstream create the branch as well wasn't another bad\n> > decision, as the name suggests it's for setting that information after\n> > the branch has already been created.\n> \n> You should be able to correct that for --set-upstream-to=.\n> It is clearly about setting upstream for an existing branch, right?\n\nYeah, it's for changing the tracking information and should refuse to do\nso if the branch doesn't exist yet.\n\n cmn\n"},{"id":"195246","messageId":"7vpq7twr13.fsf@alter.siamese.dyndns.org","threadId":"30956","inReplyTo":"1341561809.10752.61.camel@flaca.cmartin.tk","subject":"Re: [PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-18T05:56:56Z","receivedAt":"2012-07-18T05:56:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ping on a seemingly stalled discussion (no need to rush but just\nchecking).\n"},{"id":"195291","messageId":"1342625622.3852.5.camel@centaur.cmartin.tk","threadId":"30956","inReplyTo":"7vpq7twr13.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-18T15:33:42Z","receivedAt":"2012-07-18T15:33:42Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Tue, 2012-07-17 at 22:56 -0700, Junio C Hamano wrote:\n> Ping on a seemingly stalled discussion (no need to rush but just\n> checking).\n\nI've implemented the feedback, but been slacking on writing the tests\nwhich is what's stopped me from re-sending the series.\n\n\n cmn\n"},{"id":"197126","messageId":"7vipcizeg0.fsf@alter.siamese.dyndns.org","threadId":"30956","inReplyTo":"1342625622.3852.5.camel@centaur.cmartin.tk","subject":"Re: [PATCH] branch: make --set-upstream saner without an explicit starting point","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-16T21:58:55Z","receivedAt":"2012-08-16T21:58:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto writes:\n\n> On Tue, 2012-07-17 at 22:56 -0700, Junio C Hamano wrote:\n>> Ping on a seemingly stalled discussion (no need to rush but just\n>> checking).\n>\n> I've implemented the feedback, but been slacking on writing the tests\n> which is what's stopped me from re-sending the series.\n\nAnother mild ping.\n"}]}