{"thread":{"id":"30991","subject":"[PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch","startedAt":"2012-07-10T16:52:58Z","lastAt":"2012-07-12T16:58:37Z","messageCount":29,"participants":["Carlos Martín Nieto","Matthieu Moy","Junio C Hamano","Jonathan Nieder","Miles Bader"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"194866","messageId":"1341939181-8962-1-git-send-email-cmn@elego.de","threadId":"30991","inReplyTo":null,"subject":"[PATCH 0/3] A better way of handling upstream information in git-branch","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-10T16:52:58Z","receivedAt":"2012-07-10T16:52:58Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"Hello all,\n\nThis stems from comments made by Junio and Jonathan about my proposed\nchanges to --set-upstream.\n\nThis should probably have a few tests, but I'd like to hear comments\nabout the code and documentation first. The third patch is the one I'm\nnot so confident about. It would be simpler to remove the whole\nbranch.foo configuration, but that wouldn't be very safe, as we may\nhave more things there (either the future git or some external tool).\n\nCarlos Martín Nieto (3):\n  branch: introduce --set-upstream-to\n  branch: suggest how to undo a --set-upstream when given one branch\n  branch: add --unset-upstream option\n\n Documentation/git-branch.txt |   14 +++++++++++-\n builtin/branch.c             |   50 +++++++++++++++++++++++++++++++++++++++---\n 2 files changed, 60 insertions(+), 4 deletions(-)\n\n-- \n1.7.10.2.1.g8c77c3c\n"},{"id":"194868","messageId":"1341939181-8962-2-git-send-email-cmn@elego.de","threadId":"30991","inReplyTo":"1341939181-8962-1-git-send-email-cmn@elego.de","subject":"[PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-10T16:52:59Z","receivedAt":"2012-07-10T16:52:59Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"The existing --set-uptream option can cause confusion, as it uses the\nusual branch convention of assuming a starting point of HEAD if none\nis specified, causing\n\n    git branch --set-upstream origin/master\n\nto create a new local branch 'origin/master' that tracks the current\nbranch. As --set-upstream already exists, we can't simply change its\nbehaviour. To work around this, introduce --set-upstream-to which\naccepts a compulsory argument indicating what the new upstream branch\nshould be and one optinal argument indicating which branch to change,\ndefaulting to HEAD.\n\nThe new options allows us to type\n\n    git branch --set-upstream-to origin/master\n\nto set the current branch's upstream to be origin's master.\n---\n Documentation/git-branch.txt |    9 ++++++++-\n builtin/branch.c             |   15 +++++++++++++--\n 2 files changed, 21 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 47235be..0f33fc7 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -13,6 +13,7 @@ SYNOPSIS\n \t[--column[=<options>] | --no-column]\n \t[(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]\n 'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]\n+'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]\n 'git branch' (-m | -M) [<oldbranch>] <newbranch>\n 'git branch' (-d | -D) [-r] <branchname>...\n 'git branch' --edit-description [<branchname>]\n@@ -48,7 +49,7 @@ branch so that 'git pull' will appropriately merge from\n the remote-tracking branch. This behavior may be changed via the global\n `branch.autosetupmerge` configuration flag. That setting can be\n overridden by using the `--track` and `--no-track` options, and\n-changed later using `git branch --set-upstream`.\n+changed later using `git branch --set-upstream-to`.\n \n With a `-m` or `-M` option, <oldbranch> will be renamed to <newbranch>.\n If <oldbranch> had a corresponding reflog, it is renamed to match\n@@ -173,6 +174,12 @@ start-point is either a local or remote-tracking branch.\n \tlike `--track` would when creating the branch, except that where\n \tbranch points to is not changed.\n \n+-u <upstream>::\n+--set-upstream-to=<upstream>::\n+\tSet up <branchname>'s tracking information so <upstream> is\n+\tconsidered <branchname>'s upstream branch. If no branch is\n+\tspecified it defaults to the current branch.\n+\n --edit-description::\n \tOpen an editor and edit the text to explain what the branch is\n \tfor, to be used by various other commands (e.g. `request-pull`).\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 0e060f2..c886fc0 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -713,6 +713,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \tint verbose = 0, abbrev = -1, detached = 0;\n \tint reflog = 0, edit_description = 0;\n \tint quiet = 0;\n+\tconst char *new_upstream = NULL;\n \tenum branch_track track;\n \tint kinds = REF_LOCAL_BRANCH;\n \tstruct commit_list *with_commit = NULL;\n@@ -726,6 +727,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tBRANCH_TRACK_EXPLICIT),\n \t\tOPT_SET_INT( 0, \"set-upstream\",  &track, \"change upstream info\",\n \t\t\tBRANCH_TRACK_OVERRIDE),\n+\t\tOPT_STRING('u', \"set-upstream-to\", &new_upstream, \"upstream\", \"change the upstream info\"),\n \t\tOPT__COLOR(&branch_use_color, \"use colored output\"),\n \t\tOPT_SET_INT('r', \"remotes\",     &kinds, \"act on remote-tracking branches\",\n \t\t\tREF_REMOTE_BRANCH),\n@@ -794,10 +796,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \targc = parse_options(argc, argv, prefix, options, builtin_branch_usage,\n \t\t\t     0);\n \n-\tif (!delete && !rename && !edit_description && argc == 0)\n+\tif (!delete && !rename && !edit_description && !new_upstream && argc == 0)\n \t\tlist = 1;\n \n-\tif (!!delete + !!rename + !!force_create + !!list > 1)\n+\tif (!!delete + !!rename + !!force_create + !!list + !!new_upstream > 1)\n \t\tusage_with_options(builtin_branch_usage, options);\n \n \tif (abbrev == -1)\n@@ -852,6 +854,15 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\trename_branch(argv[0], argv[1], rename > 1);\n \t\telse\n \t\t\tusage_with_options(builtin_branch_usage, options);\n+\t} else if (new_upstream) {\n+\t\tstruct branch *branch = branch_get(argv[0]);\n+\n+\t\tif (!ref_exists(branch->refname))\n+\t\t  die(_(\"branch '%s' does not exist\"), branch->name);\n+\n+\t\t/* create_branch takes care of setting up the tracking\n+\t\t   info and making sure new_upstream is correct */\n+\t\tcreate_branch(head, branch->name, new_upstream, 0, 0, 0, quiet, BRANCH_TRACK_OVERRIDE);\n \t} else if (argc > 0 && argc <= 2) {\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-- \n1.7.10.2.1.g8c77c3c\n"},{"id":"194865","messageId":"1341939181-8962-3-git-send-email-cmn@elego.de","threadId":"30991","inReplyTo":"1341939181-8962-1-git-send-email-cmn@elego.de","subject":"[PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-10T16:53:00Z","receivedAt":"2012-07-10T16:53:00Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"This interface is error prone, and a better one (--set-upstream-to)\nexists. Suggest how to fix a --set-upstream invocation in case the\nuser only gives one argument, which makes it likely that he meant to\ndo the opposite, like with\n\n    git branch --set-upstream origin/master\n\nwhen they meant one of\n\n    git branch --set-upstream origin/master master\n    git branch --set-upstream-to origin/master\n\nSigned-off-by: Carlos Martín Nieto <cmn@elego.de>\n---\n builtin/branch.c |   22 ++++++++++++++++++++++\n 1 file changed, 22 insertions(+)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex c886fc0..5551227 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t   info and making sure new_upstream is correct */\n \t\tcreate_branch(head, branch->name, new_upstream, 0, 0, 0, quiet, BRANCH_TRACK_OVERRIDE);\n \t} else if (argc > 0 && argc <= 2) {\n+\t\tstruct branch *branch = branch_get(argv[0]);\n+\t\tconst char *old_upstream = NULL;\n+\t\tint branch_existed = 0;\n+\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+\n+\t\t/* Save what argv[0] was pointing to so we can give\n+\t\t   the --set-upstream-to hint */\n+\t\tif (branch_has_merge_config(branch))\n+\t\t  old_upstream = shorten_unambiguous_ref(branch->merge[0]->dst, 0);\n+\n+\t\tbranch_existed = ref_exists(branch->refname);\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\tif (argc == 1) {\n+\t\t\tprintf(\"If you wanted to make '%s' track '%s', do this:\\n\", head, argv[0]);\n+\t\t\tif (branch_existed)\n+\t\t\t\tprintf(\" $ git branch --set-upstream '%s' '%s'\\n\", argv[0], old_upstream);\n+\t\t\telse\n+\t\t\t\tprintf(\" $ git branch -d '%s'\\n\", argv[0]);\n+\n+\t\t\tprintf(\" $ git branch --set-upstream-to '%s'\\n\", argv[0]);\n+\t\t}\n+\n \t} else\n \t\tusage_with_options(builtin_branch_usage, options);\n \n-- \n1.7.10.2.1.g8c77c3c\n"},{"id":"194867","messageId":"1341939181-8962-4-git-send-email-cmn@elego.de","threadId":"30991","inReplyTo":"1341939181-8962-1-git-send-email-cmn@elego.de","subject":"[PATCH 3/3] branch: add --unset-upstream option","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-10T16:53:01Z","receivedAt":"2012-07-10T16:53:01Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"We have ways of setting the upstream information, but if we want to\nunset it, we need to resort to modifying the configuration manually.\n\nTeach branch an --unset-upstream option that unsets this information.\n\n---\n\ncreate_branch() uses install_branch_config() which may also set\nbranch.foo.rebase, so this version might leave some configuration\nlaying around.\n\nI wonder if deleting the whole branch.foo section would be better. Can\nwe be sure that nothing else shows up there?\n\n Documentation/git-branch.txt |    5 +++++\n builtin/branch.c             |   17 ++++++++++++++---\n 2 files changed, 19 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 0f33fc7..c7cab08 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -14,6 +14,7 @@ SYNOPSIS\n \t[(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]\n 'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]\n 'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]\n+'git branch' --unset-upstream [<branchname>]\n 'git branch' (-m | -M) [<oldbranch>] <newbranch>\n 'git branch' (-d | -D) [-r] <branchname>...\n 'git branch' --edit-description [<branchname>]\n@@ -180,6 +181,10 @@ start-point is either a local or remote-tracking branch.\n \tconsidered <branchname>'s upstream branch. If no branch is\n \tspecified it defaults to the current branch.\n \n+--unset-upstream::\n+\tRemove the upstream information for <branchname>. If no branch\n+\tis specified it defaults to the current branch.\n+\n --edit-description::\n \tOpen an editor and edit the text to explain what the branch is\n \tfor, to be used by various other commands (e.g. `request-pull`).\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 5551227..1d1bf8e 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -712,7 +712,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \tint delete = 0, rename = 0, force_create = 0, list = 0;\n \tint verbose = 0, abbrev = -1, detached = 0;\n \tint reflog = 0, edit_description = 0;\n-\tint quiet = 0;\n+\tint quiet = 0, unset_upstream = 0;\n \tconst char *new_upstream = NULL;\n \tenum branch_track track;\n \tint kinds = REF_LOCAL_BRANCH;\n@@ -728,6 +728,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tOPT_SET_INT( 0, \"set-upstream\",  &track, \"change upstream info\",\n \t\t\tBRANCH_TRACK_OVERRIDE),\n \t\tOPT_STRING('u', \"set-upstream-to\", &new_upstream, \"upstream\", \"change the upstream info\"),\n+\t\tOPT_BOOLEAN(0, \"unset-upstream\", &unset_upstream, \"Unset the upstream info\"),\n \t\tOPT__COLOR(&branch_use_color, \"use colored output\"),\n \t\tOPT_SET_INT('r', \"remotes\",     &kinds, \"act on remote-tracking branches\",\n \t\t\tREF_REMOTE_BRANCH),\n@@ -796,10 +797,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \targc = parse_options(argc, argv, prefix, options, builtin_branch_usage,\n \t\t\t     0);\n \n-\tif (!delete && !rename && !edit_description && !new_upstream && argc == 0)\n+\tif (!delete && !rename && !edit_description && !new_upstream && !unset_upstream && argc == 0)\n \t\tlist = 1;\n \n-\tif (!!delete + !!rename + !!force_create + !!list + !!new_upstream > 1)\n+\tif (!!delete + !!rename + !!force_create + !!list + !!new_upstream + !!unset_upstream > 1)\n \t\tusage_with_options(builtin_branch_usage, options);\n \n \tif (abbrev == -1)\n@@ -863,6 +864,16 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t/* create_branch takes care of setting up the tracking\n \t\t   info and making sure new_upstream is correct */\n \t\tcreate_branch(head, branch->name, new_upstream, 0, 0, 0, quiet, BRANCH_TRACK_OVERRIDE);\n+\t} else if (unset_upstream) {\n+\t\tstruct branch *branch = branch_get(argv[0]);\n+\t\tstruct strbuf buf = STRBUF_INIT;\n+\n+\t\tstrbuf_addf(&buf, \"branch.%s.remote\", branch->name);\n+\t\tgit_config_set_multivar(buf.buf, NULL, NULL, 1);\n+\t\tstrbuf_reset(&buf);\n+\t\tstrbuf_addf(&buf, \"branch.%s.merge\", branch->name);\n+\t\tgit_config_set_multivar(buf.buf, NULL, NULL, 1);\n+\t\tstrbuf_release(&buf);\n \t} else if (argc > 0 && argc <= 2) {\n \t\tstruct branch *branch = branch_get(argv[0]);\n \t\tconst char *old_upstream = NULL;\n-- \n1.7.10.2.1.g8c77c3c\n"},{"id":"194869","messageId":"vpq394zo86k.fsf@bauges.imag.fr","threadId":"30991","inReplyTo":"1341939181-8962-2-git-send-email-cmn@elego.de","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-07-10T17:08:35Z","receivedAt":"2012-07-10T17:08:35Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Carlos Martín Nieto <cmn@elego.de> writes:\n\n> The new options allows us to type\n>\n>     git branch --set-upstream-to origin/master\n\nThis is cool :-).\n\n>  Documentation/git-branch.txt |    9 ++++++++-\n>  builtin/branch.c             |   15 +++++++++++++--\n\nI think this deserves a few new tests (probably in t/t3200-branch.sh).\n\n> +-u <upstream>::\n> +--set-upstream-to=<upstream>::\n> +\tSet up <branchname>'s tracking information so <upstream> is\n> +\tconsidered <branchname>'s upstream branch. If no branch is\n> +\tspecified it defaults to the current branch.\n\nPerhaps \"if <branchname> is not specified, then it defaults to the\ncurrent branch.\". The current wording does not make it very clear if \"no\nbranch is specified\" refers to <branchname> or <upstream> (although the\nsecond option would be plain silly).\n\n> +\t} else if (new_upstream) {\n> +\t\tstruct branch *branch = branch_get(argv[0]);\n> +\n> +\t\tif (!ref_exists(branch->refname))\n> +\t\t  die(_(\"branch '%s' does not exist\"), branch->name);\n\nIndentation (2 spaces -> tab).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"194870","messageId":"vpqpq83mt2g.fsf@bauges.imag.fr","threadId":"30991","inReplyTo":"1341939181-8962-3-git-send-email-cmn@elego.de","subject":"Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-07-10T17:20:23Z","receivedAt":"2012-07-10T17:20:23Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Carlos Martín Nieto <cmn@elego.de> writes:\n\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n>  \t\t   info and making sure new_upstream is correct */\n>  \t\tcreate_branch(head, branch->name, new_upstream, 0, 0, 0, quiet, BRANCH_TRACK_OVERRIDE);\n>  \t} else if (argc > 0 && argc <= 2) {\n> +\t\tstruct branch *branch = branch_get(argv[0]);\n> +\t\tconst char *old_upstream = NULL;\n> +\t\tint branch_existed = 0;\n> +\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> +\n> +\t\t/* Save what argv[0] was pointing to so we can give\n> +\t\t   the --set-upstream-to hint */\n\nMulti-line comments are usually written in Git as\n\n/*\n * multi-line\n * comment\n */\n\n> +\t\tif (branch_has_merge_config(branch))\n> +\t\t  old_upstream = shorten_unambiguous_ref(branch->merge[0]->dst, 0);\n\nBroken indentation.\n\n> +\t\tif (argc == 1) {\n> +\t\t\tprintf(\"If you wanted to make '%s' track '%s', do this:\\n\", head, argv[0]);\n\nCould be marked for translation with _(\"...\").\n\n> +\t\t\tif (branch_existed)\n> +\t\t\t\tprintf(\" $ git branch --set-upstream '%s' '%s'\\n\", argv[0], old_upstream);\n\nold_upstream may be NULL at this point. I guess you want to skip this\nline if old_upsteam is NULL.\n\nThe fact that I could find this bug suggests that this lacks a few new\ntests too ;-).\n\n> +\t\t\telse\n> +\t\t\t\tprintf(\" $ git branch -d '%s'\\n\", argv[0]);\n> +\n> +\t\t\tprintf(\" $ git branch --set-upstream-to '%s'\\n\", argv[0]);\n\nFor the 3 printf()s: we usually display commands without the \"$\", and\nseparate them from text with a blank line. See for example what \"git\ncommit\" says when you didn't provide authorship:\n\nYou can suppress this message by setting them explicitly:\n\n    git config --global user.name \"Your Name\"\n    git config --global user.email you@example.com\n\nAfter doing this, you may fix the identity used for this commit with:\n\n    git commit --amend --reset-author\n\n(the absence of $ sign avoids the temptation to cut-and-paste it)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"194871","messageId":"7vehojil2g.fsf@alter.siamese.dyndns.org","threadId":"30991","inReplyTo":"1341939181-8962-2-git-send-email-cmn@elego.de","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-10T17:26:47Z","receivedAt":"2012-07-10T17:26:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto <cmn@elego.de> writes:\n\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index 0e060f2..c886fc0 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -713,6 +713,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n>  \tint verbose = 0, abbrev = -1, detached = 0;\n>  \tint reflog = 0, edit_description = 0;\n>  \tint quiet = 0;\n> +\tconst char *new_upstream = NULL;\n>  \tenum branch_track track;\n>  \tint kinds = REF_LOCAL_BRANCH;\n>  \tstruct commit_list *with_commit = NULL;\n> @@ -726,6 +727,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n>  \t\t\tBRANCH_TRACK_EXPLICIT),\n>  \t\tOPT_SET_INT( 0, \"set-upstream\",  &track, \"change upstream info\",\n>  \t\t\tBRANCH_TRACK_OVERRIDE),\n> +\t\tOPT_STRING('u', \"set-upstream-to\", &new_upstream, \"upstream\", \"change the upstream info\"),\n>  \t\tOPT__COLOR(&branch_use_color, \"use colored output\"),\n>  \t\tOPT_SET_INT('r', \"remotes\",     &kinds, \"act on remote-tracking branches\",\n>  \t\t\tREF_REMOTE_BRANCH),\n> @@ -794,10 +796,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n>  \targc = parse_options(argc, argv, prefix, options, builtin_branch_usage,\n>  \t\t\t     0);\n>  \n> -\tif (!delete && !rename && !edit_description && argc == 0)\n> +\tif (!delete && !rename && !edit_description && !new_upstream && argc == 0)\n>  \t\tlist = 1;\n>  \n> -\tif (!!delete + !!rename + !!force_create + !!list > 1)\n> +\tif (!!delete + !!rename + !!force_create + !!list + !!new_upstream > 1)\n>  \t\tusage_with_options(builtin_branch_usage, options);\n\nIt probably is an error to have track and new_upstream together.\n\nThe remainder of [Patch 1/3] looked entirely sensible, including the\nproposed log message (modulo missing sign-off).\n\nThanks.\n"},{"id":"194873","messageId":"7va9z7ikfi.fsf@alter.siamese.dyndns.org","threadId":"30991","inReplyTo":"1341939181-8962-3-git-send-email-cmn@elego.de","subject":"Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-10T17:40:33Z","receivedAt":"2012-07-10T17:40:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto <cmn@elego.de> writes:\n\n> This interface is error prone, and a better one (--set-upstream-to)\n> exists. Suggest how to fix a --set-upstream invocation in case the\n> user only gives one argument, which makes it likely that he meant to\n> do the opposite, like with\n>\n>     git branch --set-upstream origin/master\n>\n> when they meant one of\n>\n>     git branch --set-upstream origin/master master\n>     git branch --set-upstream-to origin/master\n>\n> Signed-off-by: Carlos Martín Nieto <cmn@elego.de>\n\nThe new code does not seem to depend on the value of \"track\" (which\nis set by either -t or --set-upstream) in any way.  Shouldn't it be\ndone only when it is set to track-override?\n\nDoesn't \"git branch [-f] frotz\" without any other argument trigger\nthe warning?\n\n>  builtin/branch.c |   22 ++++++++++++++++++++++\n>  1 file changed, 22 insertions(+)\n>\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index c886fc0..5551227 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n>  \t\t   info and making sure new_upstream is correct */\n>  \t\tcreate_branch(head, branch->name, new_upstream, 0, 0, 0, quiet, BRANCH_TRACK_OVERRIDE);\n>  \t} else if (argc > 0 && argc <= 2) {\n> +\t\tstruct branch *branch = branch_get(argv[0]);\n> +\t\tconst char *old_upstream = NULL;\n> +\t\tint branch_existed = 0;\n> +\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> +\n> +\t\t/* Save what argv[0] was pointing to so we can give\n> +\t\t   the --set-upstream-to hint */\n> +\t\tif (branch_has_merge_config(branch))\n> +\t\t  old_upstream = shorten_unambiguous_ref(branch->merge[0]->dst, 0);\n> +\n> +\t\tbranch_existed = ref_exists(branch->refname);\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\tif (argc == 1) {\n> +\t\t\tprintf(\"If you wanted to make '%s' track '%s', do this:\\n\", head, argv[0]);\n> +\t\t\tif (branch_existed)\n> +\t\t\t\tprintf(\" $ git branch --set-upstream '%s' '%s'\\n\", argv[0], old_upstream);\n> +\t\t\telse\n> +\t\t\t\tprintf(\" $ git branch -d '%s'\\n\", argv[0]);\n> +\n> +\t\t\tprintf(\" $ git branch --set-upstream-to '%s'\\n\", argv[0]);\n> +\t\t}\n> +\n>  \t} else\n>  \t\tusage_with_options(builtin_branch_usage, options);\n"},{"id":"194874","messageId":"7v629vijf2.fsf@alter.siamese.dyndns.org","threadId":"30991","inReplyTo":"1341939181-8962-4-git-send-email-cmn@elego.de","subject":"Re: [PATCH 3/3] branch: add --unset-upstream option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-10T18:02:25Z","receivedAt":"2012-07-10T18:02:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto <cmn@elego.de> writes:\n\n> We have ways of setting the upstream information, but if we want to\n> unset it, we need to resort to modifying the configuration manually.\n>\n> Teach branch an --unset-upstream option that unsets this information.\n>\n> ---\n>\n> create_branch() uses install_branch_config() which may also set\n> branch.foo.rebase, so this version might leave some configuration\n> laying around.\n>\n> I wonder if deleting the whole branch.foo section would be better. Can\n> we be sure that nothing else shows up there?\n\n\"branch.foo.$unknown\" may not be related to upstream at all, so that\nwill not fly.  Besides, we already have unknown=description, no?\n\nIf you are removing the branch \"foo\", it would make sense, though.\n\n> +\t} else if (unset_upstream) {\n> +\t\tstruct branch *branch = branch_get(argv[0]);\n> +\t\tstruct strbuf buf = STRBUF_INIT;\n> +\n> +\t\tstrbuf_addf(&buf, \"branch.%s.remote\", branch->name);\n> +\t\tgit_config_set_multivar(buf.buf, NULL, NULL, 1);\n\nThis part makes sense, as \"--set-upstream\" is about setting the\nvalue of branch.foo.remote to 'origin' or whatever.\n\n> +\t\tstrbuf_reset(&buf);\n> +\t\tstrbuf_addf(&buf, \"branch.%s.merge\", branch->name);\n> +\t\tgit_config_set_multivar(buf.buf, NULL, NULL, 1);\n\nThis also makes sense because \"branch.foo.merge\" names a ref in the\ncontext of the remote.  A branch may have integrated with the \"dev\"\nbranch at \"origin\" repository; when it is modified to slurp changes\nfrom \"central\" repository from now on, there is nothing that says\nthat the branch \"dev\" at this different remote corresponds to the\n\"dev\" branch at the original \"origin\" repository (such a branch may\nnot even exist at the new \"central\" repository).  There is no point\nleaving the \"branch.foo.merge\" configuration behind when you unset\nthe upstream information.\n\n\n\n> +\t\tstrbuf_release(&buf);\n>  \t} else if (argc > 0 && argc <= 2) {\n>  \t\tstruct branch *branch = branch_get(argv[0]);\n>  \t\tconst char *old_upstream = NULL;\n"},{"id":"194875","messageId":"20120710191354.GE8439@burratino","threadId":"30991","inReplyTo":"1341939181-8962-2-git-send-email-cmn@elego.de","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-07-10T19:13:54Z","receivedAt":"2012-07-10T19:13:54Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nCarlos Martín Nieto wrote:\n\n> The existing --set-uptream option can cause confusion, as it uses the\n> usual branch convention of assuming a starting point of HEAD if none\n> is specified, causing\n>\n>     git branch --set-upstream origin/master\n>\n> to create a new local branch 'origin/master' that tracks the current\n> branch. As --set-upstream already exists, we can't simply change its\n> behaviour. To work around this, introduce --set-upstream-to which\n> accepts a compulsory argument\n\nThanks.  A part of me really dislikes this --set-upstream-to which\nis named more awkwardly than the deprecated mistake it replaces,\nthough.\n\nHere's a patch on top to play with that names the new option\n\"--set-upstream=\".  Untested.\n\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\n---\ndiff --git i/Documentation/git-branch.txt w/Documentation/git-branch.txt\nindex f572913f..57935a64 100644\n--- i/Documentation/git-branch.txt\n+++ w/Documentation/git-branch.txt\n@@ -49,7 +49,7 @@ branch so that 'git pull' will appropriately merge from\n the remote-tracking branch. This behavior may be changed via the global\n `branch.autosetupmerge` configuration flag. That setting can be\n overridden by using the `--track` and `--no-track` options, and\n-changed later using `git branch --set-upstream-to`.\n+changed later using `git branch --set-upstream`.\n \n With a `-m` or `-M` option, <oldbranch> will be renamed to <newbranch>.\n If <oldbranch> had a corresponding reflog, it is renamed to match\n@@ -174,11 +174,13 @@ start-point is either a local or remote-tracking branch.\n \tlike `--track` would when creating the branch, except that where\n \tbranch points to is not changed.\n \n--u <upstream>::\n---set-upstream-to=<upstream>::\n+--set-upstream=<upstream>::\n \tSet up <branchname>'s tracking information so <upstream> is\n \tconsidered <branchname>'s upstream branch. If no branch is\n \tspecified it defaults to the current branch.\n++\n+If no argument is attached, for historical reasons the meaning is\n+different.  See above.\n \n --edit-description::\n \tOpen an editor and edit the text to explain what the branch is\ndiff --git i/builtin/branch.c w/builtin/branch.c\nindex c886fc06..0d705790 100644\n--- i/builtin/branch.c\n+++ w/builtin/branch.c\n@@ -669,6 +669,31 @@ static int opt_parse_merge_filter(const struct option *opt, const char *arg, int\n \treturn 0;\n }\n \n+struct set_upstream_params {\n+\tenum branch_track *track;\n+\tconst char **new_upstream;\n+};\n+static int parse_opt_set_upstream(const struct option *opt, const char *arg, int unset)\n+{\n+\tstruct set_upstream_params *o = opt->value;\n+\n+\tif (unset) {\t/* --no-set-upstream */\n+\t\t*o->track = BRANCH_TRACK_NEVER;\n+\t\t*o->new_upstream = NULL;\n+\t\treturn 0;\n+\t}\n+\n+\t*o->track = BRANCH_TRACK_OVERRIDE;\n+\tif (!arg)\t/* --set-upstream <branchname> <start-point> */\n+\t\t*o->new_upstream = NULL;\n+\telse\t/* --set-upstream=<upstream> <branchname> */\n+\t\t*o->new_upstream = arg;\n+\treturn 0;\n+}\n+#define OPT_SET_UPSTREAM(s, l, v) \\\n+\t{ OPTION_CALLBACK, (s), (l), (v), \"upstream\", \"change upstream info\", \\\n+\t  PARSE_OPT_OPTARG, &parse_opt_set_upstream }\n+\n static const char edit_description[] = \"BRANCH_DESCRIPTION\";\n \n static int edit_branch_description(const char *branch_name)\n@@ -716,6 +741,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \tconst char *new_upstream = NULL;\n \tenum branch_track track;\n \tint kinds = REF_LOCAL_BRANCH;\n+\tstruct set_upstream_params set_upstream_args = { &track, &new_upstream };\n \tstruct commit_list *with_commit = NULL;\n \n \tstruct option options[] = {\n@@ -725,9 +751,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tOPT__QUIET(&quiet, \"suppress informational messages\"),\n \t\tOPT_SET_INT('t', \"track\",  &track, \"set up tracking mode (see git-pull(1))\",\n \t\t\tBRANCH_TRACK_EXPLICIT),\n-\t\tOPT_SET_INT( 0, \"set-upstream\",  &track, \"change upstream info\",\n-\t\t\tBRANCH_TRACK_OVERRIDE),\n-\t\tOPT_STRING('u', \"set-upstream-to\", &new_upstream, \"upstream\", \"change the upstream info\"),\n+\t\tOPT_SET_UPSTREAM(0, \"set-upstream\", &set_upstream_args),\n \t\tOPT__COLOR(&branch_use_color, \"use colored output\"),\n \t\tOPT_SET_INT('r', \"remotes\",     &kinds, \"act on remote-tracking branches\",\n \t\t\tREF_REMOTE_BRANCH),\n"},{"id":"194876","messageId":"20120710192408.GF8439@burratino","threadId":"30991","inReplyTo":"1341939181-8962-3-git-send-email-cmn@elego.de","subject":"Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-07-10T19:24:08Z","receivedAt":"2012-07-10T19:24:08Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nQuick nitpicks.\n\nCarlos Martín Nieto wrote:\n\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n>  \t\t   info and making sure new_upstream is correct */\n>  \t\tcreate_branch(head, branch->name, new_upstream, 0, 0, 0, quiet, BRANCH_TRACK_OVERRIDE);\n>  \t} else if (argc > 0 && argc <= 2) {\n> +\t\tstruct branch *branch = branch_get(argv[0]);\n> +\t\tconst char *old_upstream = NULL;\n> +\t\tint branch_existed = 0;\n> +\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> +\n> +\t\t/* Save what argv[0] was pointing to so we can give\n> +\t\t   the --set-upstream-to hint */\n> +\t\tif (branch_has_merge_config(branch))\n> +\t\t  old_upstream = shorten_unambiguous_ref(branch->merge[0]->dst, 0);\n\nWhitespace is odd here.  Maybe this case could be factored out as a\nnew function to make room on the right margin and make cmd_branch()\neasier to read straight through.\n\n> +\n> +\t\tbranch_existed = ref_exists(branch->refname);\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\tif (argc == 1) {\n> +\t\t\tprintf(\"If you wanted to make '%s' track '%s', do this:\\n\", head, argv[0]);\n> +\t\t\tif (branch_existed)\n> +\t\t\t\tprintf(\" $ git branch --set-upstream '%s' '%s'\\n\", argv[0], old_upstream);\n> +\t\t\telse\n> +\t\t\t\tprintf(\" $ git branch -d '%s'\\n\", argv[0]);\n> +\n> +\t\t\tprintf(\" $ git branch --set-upstream-to '%s'\\n\", argv[0]);\n\nMessage should go on stderr and be guarded with an advice option (see\nadvice.c).\n\nLike this:\n\n\tconst char *arg;\n\n\t...\n\tif (argc != 1 || !advice_old_fashioned_set_upstream)\n\t\treturn 0; /* ok. */\n\n\targ = argv[0];\n\tadvise(\"If you wanted to make '%s' track '%s', do this:\",\n\t\t\t\t\t\t\thead, arg);\n\tif (branch_existed)\n\t\tadvise(\" $ git branch --set-upstream-to='%s' '%s'\",\n\t\t\told_upstream, arg);\n\telse\n\t\tadvise(\" $ git branch -d '%s'\", arg);\n\tadvise(\" $ git branch --set-upstream-to='%s'\", arg);\n\nIf an argument contains single-quotes, the quoting will be wrong, but\nthat's probably not worth worrying about.\n\nHope that helps,\nJonathan\n"},{"id":"194877","messageId":"7v1ukjiehe.fsf@alter.siamese.dyndns.org","threadId":"30991","inReplyTo":"20120710191354.GE8439@burratino","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-10T19:49:01Z","receivedAt":"2012-07-10T19:49:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>> The existing --set-uptream option can cause confusion, as it uses the\n>> usual branch convention of assuming a starting point of HEAD if none\n>> is specified, causing\n>>\n>>     git branch --set-upstream origin/master\n>>\n>> to create a new local branch 'origin/master' that tracks the current\n>> branch. As --set-upstream already exists, we can't simply change its\n>> behaviour. To work around this, introduce --set-upstream-to which\n>> accepts a compulsory argument\n>\n> Thanks.  A part of me really dislikes this --set-upstream-to which\n> is named more awkwardly than the deprecated mistake it replaces,\n> though.\n\nI am not super excited about it either, but at least it is a vast\nimprovement compared to the older one, with which it was entirely\nunclear if we are setting the value of upstream *to* what is given\nas an option, or setting the upstream *for* what is given on the\ncommand line.\n"},{"id":"194878","messageId":"20120710201105.GH8439@burratino","threadId":"30991","inReplyTo":"7v1ukjiehe.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-07-10T20:11:05Z","receivedAt":"2012-07-10T20:11:05Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> I am not super excited about it either, but at least it is a vast\n> improvement compared to the older one, with which it was entirely\n> unclear if we are setting the value of upstream *to* what is given\n> as an option, or setting the upstream *for* what is given on the\n> command line.\n\nAh, do you mean that --set-upstream is meant to have usage like\n\"git remote set-url\" and co?\n\n\tgit remote set-url <remote> <url>\n\tgit branch --set-upstream <branch> <upstream>\n\nThat's a reasonable stance, and it seems possible to get used to it.\nIn that case, we should just teach --set-upstream not to create\nnew branches, and people will get used to it.\n\nThe immediate problem that seems to trip people up is that it is very\ntempting to run\n\n\tgit branch --set-upstream junio/master\n\nin an attempt to change what is upstream to the current branch, and\nthe result is some other completely counterintuitive thing.  I suspect\nthe order of arguments to --set-upstream is a red herring, as long as\nit errors out when the arguments are switched to help people catch\nmistakes.\n"},{"id":"194883","messageId":"7vsjczgx3h.fsf@alter.siamese.dyndns.org","threadId":"30991","inReplyTo":"20120710201105.GH8439@burratino","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-10T20:49:54Z","receivedAt":"2012-07-10T20:49:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> The immediate problem that seems to trip people up is that it is very\n> tempting to run\n>\n> \tgit branch --set-upstream junio/master\n\nI think we have discussed this already a few days ago.  See my\ncomment in the earlier thread before this round.\n"},{"id":"194885","messageId":"20120710210901.GI8439@burratino","threadId":"30991","inReplyTo":"7vsjczgx3h.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-07-10T21:09:01Z","receivedAt":"2012-07-10T21:09:01Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>> The immediate problem that seems to trip people up is that it is very\n>> tempting to run\n>>\n>> \tgit branch --set-upstream junio/master\n>\n> I think we have discussed this already a few days ago.  See my\n> comment in the earlier thread before this round.\n\nYou wrote[*]:\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\n\nwith which I completely agree.  You then moved on to\n\n|                                                               and\n[someone should have]\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\nwith which I disagree.\n\nAs far as I can tell, nobody really thought very hard about what\n--set-upstream would do when passed only one argument.  It should have\nbeen made to error out and only later change if someone had an idea\nabout how to make it useful.\n\nLuckily we have a way out.  Any example transition plan looks like\nthe following.\n\nDAY 1.\n\n\t$ git branch --set-upstream origin/master\n\tBranch origin/master set up to track local branch debian-sid.\n\thint: If you intended to make the current branch track\n\thint: origin/master, you can recover with the following commands:\n\thint:  $ git branch -d origin/master\n\thint:  $ git branch --set-upstream master origin/master\n\t$\n\nDAY 2.\n\n\t$ git branch --set-upstream origin/master\n\tBranch origin/master set up to track local branch debian-sid.\n\twarning: using --set-upstream when creating a new branch is deprecated\n\thint: use --track instead\n\thint:\n\thint: If you intended to make the current branch track\n\thint: origin/master, you can recover with the following commands:\n\thint:  $ git branch -d origin/master\n\thint:  $ git branch --set-upstream master origin/master\n\t$\n\nDAY 3.\n\n\t$ git branch --set-upstream origin/master\n\tfatal: no such branch \"origin/master\"\n\t$\n\nDAY 4.\n\n\t$ git branch --set-upstream origin/master\n\tusage: git branch --set-upstream <branchname> <upstream>\n\t$\n\n[*] http://thread.gmane.org/gmane.comp.version-control.git/201040/focus=201051\n"},{"id":"194886","messageId":"7vliirgrun.fsf@alter.siamese.dyndns.org","threadId":"30991","inReplyTo":"20120710192408.GF8439@burratino","subject":"Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-10T22:43:12Z","receivedAt":"2012-07-10T22:43:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Message should go on stderr and be guarded with an advice option (see\n> advice.c).\n>\n> Like this:\n>\n> \tconst char *arg;\n>\n> \t...\n> \tif (argc != 1 || !advice_old_fashioned_set_upstream)\n> \t\treturn 0; /* ok. */\n>\n> \targ = argv[0];\n> \tadvise(\"If you wanted to make '%s' track '%s', do this:\",\n> \t\t\t\t\t\t\thead, arg);\n> \tif (branch_existed)\n> \t\tadvise(\" $ git branch --set-upstream-to='%s' '%s'\",\n> \t\t\told_upstream, arg);\n> \telse\n> \t\tadvise(\" $ git branch -d '%s'\", arg);\n> \tadvise(\" $ git branch --set-upstream-to='%s'\", arg);\n>\n> If an argument contains single-quotes, the quoting will be wrong, but\n> that's probably not worth worrying about.\n\nIn principle, I would agree that this is a kind of thing that falls\ninto the \"advice\" categiry, but with the fact that we plan to\ndeprecate \"--set-upstream\", combined with the fact that [PATCH 1/3]\nintroduced the new option --set-upstream-to together with a short\nand sweet -u synonym already at this point in the series, I think it\nis better to leave them emitted unconditionally to the standard\nerror stream, in order to train users away from using the old option\nthat has its arguments wrong (the option does not take an argument\nit should, and makes the command line to look as if it takes two\nbranch arguments in the wrong order).\n\nActually, we should probably add the deprecation warning in this\ncommit.\n"},{"id":"194889","messageId":"20120710230014.GA20873@burratino","threadId":"30991","inReplyTo":"7vliirgrun.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-07-10T23:00:14Z","receivedAt":"2012-07-10T23:00:14Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n>                                                           I think it\n> is better to leave them emitted unconditionally to the standard\n> error stream, in order to train users away from using the old option\n> that has its arguments wrong (the option does not take an argument\n> it should, and makes the command line to look as if it takes two\n> branch arguments in the wrong order).\n\nI thought we already discussed that that is a side-issue?\n\nThe option is a mode option for the command, like \"-m\", \"-d\", or\n\"--edit-description\".  I genuinely don't think the order of options it\ntakes is counter-intuitive.  The second argument defaulting to HEAD\nand the behavior of creating the branch named by the first argument\nwhen it does not exist are quite counter-intuitive.\n\nTransitioning to a different argument order seems like it would just\nmake the command more complicated.  After the transition, there are\ntwo options to explain, and during the transition, it is easy to make\nscripts with gratuitous incompatibilities that won't work on older\nsystems.\n\nWhere is my thinking going wrong?\n\nJonathan\n"},{"id":"194890","messageId":"7vehojgqgk.fsf@alter.siamese.dyndns.org","threadId":"30991","inReplyTo":"20120710210901.GI8439@burratino","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-10T23:13:15Z","receivedAt":"2012-07-10T23:13:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> [someone should have]\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> with which I disagree.\n\nYou can think of it this way.\n\n\"git branch\" can not only _create_ a new branch (or list existing\nones, but that is another entirely different mode), but also can be\nused to set attributes to an existing branch.  Imagine a new option,\nsay --set-description, to replace branch.frotz.description, for\nexample.  It would be used like this:\n\n\t$ git branch --set-description='add frotz feature' frotz\n\nto set the description for the 'frotz' branch (i.e. the above would\nset branch.frotz.description), and we default to HEAD if 'frotz' is\nmissing from the command line.  \"git branch --option [<branch>]\" is\nabout manipulating the branch, and we default the target of\nmanipulation to HEAD.\n\n\"upstream\" is just another kind of attribute for the branch being\nmanipulated, whose value happens to be a branch name.\n\nThe mistake was that --set-upstream was coded by piggybacking the\nexisting --track implementation where a new branch was created, and\nin that codepath, \"git branch <name1> [<name2>]\" creates <name1>\nwhile defaulting a missing <name2> to HEAD.\n\nCreating a new branch that is forked from the current HEAD is an\noften useful thing to do, so defaulting a missing <name2> (aka\n\"start-point\") to HEAD is very sensible, but reconfiguring a named\nbranch <name1> to integrate with the current branch is much less\nuseful than the other way around.  One major reason why it is so is\nbecause you would more likely set any branch to integrate with a\nremote tracking branch (rather than a local branch) and by\ndefinition your HEAD cannot be a remote tracking branch.\n\nIt makes it worse that you would often want to reconfigure the\ncurrent branch; for the purpose of reconfiguring a branch <name1> to\nintegrate with something else <name2>, it is much more likely that\nyou want a missing <name1> to default to HEAD, not the other way\naround to default a missing <name2> to HEAD, which is useful for\nbranch creation.\n\nBut switching which missing argument gets default based on what\noptions are used is insane.\n\nIf the very original \"create this new branch starting at that point\"\nwere spelled like this\n\n\t$ git branch [--start-point=<name2>] <name1>\n\nand a missing <name2> defaulted to HEAD, it probably would have been\nbetter. It would have made it very unlikely to tempt anybody to hack\nthe --set-upstream option into the system with the wrong parameter\norder if such a command line convention was in place.\n\nIf anything, it could be a sensible longer-term direction to a more\nintuitive UI to deprecate the two-name format and make the creation\nto be specified with an explicit --start-point option with an\nargument (which defaults to HEAD), but I think that falls into the\n\"if I were reinventing git without existing userbase in 2005\"\ncategory and it is too late for that.\n"},{"id":"194891","messageId":"20120710234717.GA21467@burratino","threadId":"30991","inReplyTo":"7vehojgqgk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-07-10T23:47:17Z","receivedAt":"2012-07-10T23:47:17Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> You can think of it this way.\n>\n> \"git branch\" can not only _create_ a new branch (or list existing\n> ones, but that is another entirely different mode), but also can be\n> used to set attributes to an existing branch.  Imagine a new option,\n> say --set-description, to replace branch.frotz.description, for\n> example.  It would be used like this:\n>\n> \t$ git branch --set-description='add frotz feature' frotz\n\nThat's the same question.\n\nYou say that it would be used like that.  I say that it would be\nmore intuitive, given how \"git remote\", \"git config\", and other\ncommands other than \"update-index --chmod\" that set attributes already\nwork, for it to be used like this:\n\n\tgit branch --set-description frotz 'add frotz feature'\n\nNotice how similar that is to \"git remote set-head origin master\".\nIt would just be the consistent thing to do.\n\nThe truth is that neither one of us is right.  Both conventions\ncould work, and which one is more intuitive will vary from person\nto person.  The convention used for plain \"git branch\" is\n\n\tcopy(target, source)\n\nThat matches memcpy() and is the opposite of what \"cp\" uses.  Oh\nwell.  The convention used for \"git remote add\" is\n\n\tmethod(this, args...)\n\nIt's generally pretty natural.  The convention used for \"git\nupdate-index --chmod\" is\n\n\taction(parameters)(files...)\n\nThat matches \"chmod\" so it was probably a good choice.\n\nHoping that clarifies,\nJonathan\n"},{"id":"194892","messageId":"7vzk77f602.fsf@alter.siamese.dyndns.org","threadId":"30991","inReplyTo":"20120710234717.GA21467@burratino","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-11T01:20:29Z","receivedAt":"2012-07-11T01:20:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> The truth is that neither one of us is right.  Both conventions\n> could work, and which one is more intuitive will vary from person\n> to person.\n\nIt is not just person-to-person, I think.\n\nIn short, you are saying that, assuming that missing <start> and\n<branch> are given a sane default values (namely \"HEAD\"), the\nsyntax:\n\n\tgit branch <branch> [<start>]\n\tgit branch --set-upstream-jrn [<branch>] <upstream>\n\nis easier to understand, while I think\n\n\tgit branch <branch> [<start>]\n        git branch --set-upstream-to=<upstream> [<branch>]\n\nso that omitted things can come uniformly at the end (of course,\nunless the --option=argument in the middle is omitted, that is)\nmakes things more consistent.\n\nI do not think it is productive to keep agreeing that we disagree\nand continuing to talk between ourselves without waiting for others\nto catch up, so I'll stop here.\n"},{"id":"194894","messageId":"20120711013756.GA2964@burratino","threadId":"30991","inReplyTo":"7vzk77f602.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-07-11T01:37:56Z","receivedAt":"2012-07-11T01:37:56Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> In short, you are saying that, assuming that missing <start> and\n> <branch> are given a sane default values (namely \"HEAD\"), the\n> syntax:\n>\n>\tgit branch <branch> [<start>]\n>\tgit branch --set-upstream-jrn [<branch>] <upstream>\n>\n> is easier to understand\n\nI didn't propose allowing the branch argument to be omitted, actually.\nIt would be clearest, _especially_ because one argument currently\nmeans something different, to make that error out.  Sorry for the lack\nof clarity.\n\nOne more detail I didn't mention before: I think a convenience feature\n\n\tgit branch --set-upstream-to <upstream>\n\nthat takes exactly one argument and means\n\n\tgit branch --set-upstream HEAD <upstream>\n\nwould be fine.  Having a second command to do the same thing as\n--set-upstream does (or adding new --set-other-things commands that\nuse this proposed convention where the value comes before the key) and\nmigrating awkwardly to it is what I object to.\n\nClearer?\nJonathan\n"},{"id":"194905","messageId":"1342014606.6458.7.camel@centaur.cmartin.tk","threadId":"30991","inReplyTo":"vpqpq83mt2g.fsf@bauges.imag.fr","subject":"Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-11T13:50:06Z","receivedAt":"2012-07-11T13:50:06Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Tue, 2012-07-10 at 19:20 +0200, Matthieu Moy wrote:\n> Carlos Martín Nieto <cmn@elego.de> writes:\n> \n> > --- a/builtin/branch.c\n> > +++ b/builtin/branch.c\n> > @@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n> >  \t\t   info and making sure new_upstream is correct */\n> >  \t\tcreate_branch(head, branch->name, new_upstream, 0, 0, 0, quiet, BRANCH_TRACK_OVERRIDE);\n> >  \t} else if (argc > 0 && argc <= 2) {\n> > +\t\tstruct branch *branch = branch_get(argv[0]);\n> > +\t\tconst char *old_upstream = NULL;\n> > +\t\tint branch_existed = 0;\n> > +\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> > +\n> > +\t\t/* Save what argv[0] was pointing to so we can give\n> > +\t\t   the --set-upstream-to hint */\n> \n> Multi-line comments are usually written in Git as\n> \n> /*\n>  * multi-line\n>  * comment\n>  */\n\nI've seen this style often, but sure.\n\n> \n> > +\t\tif (branch_has_merge_config(branch))\n> > +\t\t  old_upstream = shorten_unambiguous_ref(branch->merge[0]->dst, 0);\n> \n> Broken indentation.\n\nYeah, sorry. New laptop, hadn't got the default style fixed in the\nconfig.\n\n> \n> > +\t\tif (argc == 1) {\n> > +\t\t\tprintf(\"If you wanted to make '%s' track '%s', do this:\\n\", head, argv[0]);\n> \n> Could be marked for translation with _(\"...\").\n\nDone.\n\n> \n> > +\t\t\tif (branch_existed)\n> > +\t\t\t\tprintf(\" $ git branch --set-upstream '%s' '%s'\\n\", argv[0], old_upstream);\n> \n> old_upstream may be NULL at this point. I guess you want to skip this\n> line if old_upsteam is NULL.\n\nWe've just set up tracking for it, so we'd want to undo that. Which\nmeans --unset-upstream would have to move earlier in the series so we\ncan suggest that.\n\n> \n> The fact that I could find this bug suggests that this lacks a few new\n> tests too ;-).\n\nIndeed :) the next round will have them.\n\n> \n> > +\t\t\telse\n> > +\t\t\t\tprintf(\" $ git branch -d '%s'\\n\", argv[0]);\n> > +\n> > +\t\t\tprintf(\" $ git branch --set-upstream-to '%s'\\n\", argv[0]);\n> \n> For the 3 printf()s: we usually display commands without the \"$\", and\n> separate them from text with a blank line. See for example what \"git\n> commit\" says when you didn't provide authorship:\n\nYeah, I was going by what Junio wrote in his mail. We should probably\nhave a double-LF as well, like in the message below.\n\n> \n> You can suppress this message by setting them explicitly:\n> \n>     git config --global user.name \"Your Name\"\n>     git config --global user.email you@example.com\n> \n> After doing this, you may fix the identity used for this commit with:\n> \n>     git commit --amend --reset-author\n> \n> (the absence of $ sign avoids the temptation to cut-and-paste it)\n> \n"},{"id":"194906","messageId":"1342016087.6458.10.camel@centaur.cmartin.tk","threadId":"30991","inReplyTo":"7v629vijf2.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] branch: add --unset-upstream option","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-11T14:14:47Z","receivedAt":"2012-07-11T14:14:47Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Tue, 2012-07-10 at 11:02 -0700, Junio C Hamano wrote:\n> Carlos Martín Nieto <cmn@elego.de> writes:\n> \n> > We have ways of setting the upstream information, but if we want to\n> > unset it, we need to resort to modifying the configuration manually.\n> >\n> > Teach branch an --unset-upstream option that unsets this information.\n> >\n> > ---\n> >\n> > create_branch() uses install_branch_config() which may also set\n> > branch.foo.rebase, so this version might leave some configuration\n> > laying around.\n> >\n> > I wonder if deleting the whole branch.foo section would be better. Can\n> > we be sure that nothing else shows up there?\n> \n> \"branch.foo.$unknown\" may not be related to upstream at all, so that\n> will not fly.  Besides, we already have unknown=description, no?\n\nAh yes, that exists. I've added a bit of code to also remove\nbranch.foo.rebase, which I'd also consider to be part of the upstream\ninformation.\n\n   cmn\n"},{"id":"194907","messageId":"1342016695.6458.14.camel@centaur.cmartin.tk","threadId":"30991","inReplyTo":"7va9z7ikfi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-11T14:24:55Z","receivedAt":"2012-07-11T14:24:55Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Tue, 2012-07-10 at 10:40 -0700, Junio C Hamano wrote:\n> Carlos Martín Nieto <cmn@elego.de> writes:\n> \n> > This interface is error prone, and a better one (--set-upstream-to)\n> > exists. Suggest how to fix a --set-upstream invocation in case the\n> > user only gives one argument, which makes it likely that he meant to\n> > do the opposite, like with\n> >\n> >     git branch --set-upstream origin/master\n> >\n> > when they meant one of\n> >\n> >     git branch --set-upstream origin/master master\n> >     git branch --set-upstream-to origin/master\n> >\n> > Signed-off-by: Carlos Martín Nieto <cmn@elego.de>\n> \n> The new code does not seem to depend on the value of \"track\" (which\n> is set by either -t or --set-upstream) in any way.  Shouldn't it be\n> done only when it is set to track-override?\n\nYes, yes it should.\n\n> \n> Doesn't \"git branch [-f] frotz\" without any other argument trigger\n> the warning?\n\nIt does. Oops. Fixed.\n\n   cmn\n"},{"id":"194909","messageId":"1342019640.6458.23.camel@centaur.cmartin.tk","threadId":"30991","inReplyTo":"20120710230014.GA20873@burratino","subject":"Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-11T15:14:00Z","receivedAt":"2012-07-11T15:14:00Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Tue, 2012-07-10 at 18:00 -0500, Jonathan Nieder wrote:\n> Junio C Hamano wrote:\n> \n> >                                                           I think it\n> > is better to leave them emitted unconditionally to the standard\n> > error stream, in order to train users away from using the old option\n> > that has its arguments wrong (the option does not take an argument\n> > it should, and makes the command line to look as if it takes two\n> > branch arguments in the wrong order).\n> \n> I thought we already discussed that that is a side-issue?\n\nThe current --set-upstream is the whole reason for this series existing.\n\n> \n> The option is a mode option for the command, like \"-m\", \"-d\", or\n> \"--edit-description\".  I genuinely don't think the order of options it\n> takes is counter-intuitive.  The second argument defaulting to HEAD\n> and the behavior of creating the branch named by the first argument\n> when it does not exist are quite counter-intuitive.\n\nThis is confusing. First you say that you don't think it's\ncounter-intuitive but then you say it is? Or is the first part about -m\nand -d?\n\nThe second part of the paragraph is indeed what I'm trying to solve with\nthis series. If you want to create a new branch, you should be using -t.\n\n> \n> Transitioning to a different argument order seems like it would just\n> make the command more complicated.  After the transition, there are\n> two options to explain, and during the transition, it is easy to make\n> scripts with gratuitous incompatibilities that won't work on older\n> systems.\n> \n> Where is my thinking going wrong?\n\nWe're not transitioning to a new order as such, particularly not with\nthe same option name. The incompatibilities would ensue with the other\npatch I send which did change the order for --set-upstream, but what\nthis does is _add_ --set-upstream-to=<upstream> such that the option\ntakes one argument and the command takes one optional argument, which\nmakes it closer to what one would expect, specially as changing the\nupstream information is something you're most likely to do on the\ncurrent branch.\n\n   cmn\n"},{"id":"194921","messageId":"7vfw8yfde4.fsf@alter.siamese.dyndns.org","threadId":"30991","inReplyTo":"1342016087.6458.10.camel@centaur.cmartin.tk","subject":"Re: [PATCH 3/3] branch: add --unset-upstream option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-11T16:53:07Z","receivedAt":"2012-07-11T16:53:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto <cmn@elego.de> writes:\n\n> I've added a bit of code to also remove branch.foo.rebase, which\n> I'd also consider to be part of the upstream information.\n\nIf \"git branch -t\" or \"git branch --set-upstream\" took another\noption \"--integrate-with=[rebase|merge]\" to set the variable, I\nwould agree that removing branch.$name.rebase would be the right\nthing to do, but because it is not, I do not know if it is sensible\nto remove it upon --unset-upstream.\n\nI actually thought about commenting on that exact variable in my\nreview, saying that the patch was correct that it didn't touch it.\n"},{"id":"194956","messageId":"874npds75j.fsf@catnip.gol.com","threadId":"30991","inReplyTo":"7vzk77f602.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2012-07-12T08:41:44Z","receivedAt":"2012-07-12T08:41:44Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n> is easier to understand, while I think\n>\n> \tgit branch <branch> [<start>]\n>         git branch --set-upstream-to=<upstream> [<branch>]\n\nIsn't one problem with this that even if a \"--set-upstream-to\" option\nexists, inevitably some [and I'm guessing, many] people will not be\naware of it (after all, nobody reads documentation more than they have\nto), and will attempt to use \"--set-upstream\" with an argument\n(that's the natural thing to do, after all) -- which may succeed with\nweird results ...?\n\n-miles\n\n-- \nOne of the lessons of history is that nothing is often a good thing to\ndo, and always a clever thing to say.  -- Will Durant\n"},{"id":"194959","messageId":"1342088866.6458.24.camel@centaur.cmartin.tk","threadId":"30991","inReplyTo":"7vfw8yfde4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] branch: add --unset-upstream option","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-07-12T10:27:46Z","receivedAt":"2012-07-12T10:27:46Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, 2012-07-11 at 09:53 -0700, Junio C Hamano wrote:\n> Carlos Martín Nieto <cmn@elego.de> writes:\n> \n> > I've added a bit of code to also remove branch.foo.rebase, which\n> > I'd also consider to be part of the upstream information.\n> \n> If \"git branch -t\" or \"git branch --set-upstream\" took another\n> option \"--integrate-with=[rebase|merge]\" to set the variable, I\n> would agree that removing branch.$name.rebase would be the right\n> thing to do, but because it is not, I do not know if it is sensible\n> to remove it upon --unset-upstream.\n\nI'll drop it then.\n\n   cmn\n"},{"id":"194968","messageId":"7v394wdigy.fsf@alter.siamese.dyndns.org","threadId":"30991","inReplyTo":"874npds75j.fsf@catnip.gol.com","subject":"Re: [PATCH 1/3] branch: introduce --set-upstream-to","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-12T16:58:37Z","receivedAt":"2012-07-12T16:58:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader <miles@gnu.org> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>> is easier to understand, while I think\n>>\n>> \tgit branch <branch> [<start>]\n>>         git branch --set-upstream-to=<upstream> [<branch>]\n>\n> Isn't one problem with this that even if a \"--set-upstream-to\" option\n> exists, inevitably some [and I'm guessing, many] people will not be\n> aware of it (after all, nobody reads documentation more than they have\n> to), and will attempt to use \"--set-upstream\" with an argument\n> (that's the natural thing to do, after all) -- which may succeed with\n> weird results ...?\n\nIn the part you quoted in the message you are responding to in the\nsubthread between Jonathan and, I was expressing doubts about his\n\"upon seeing a single argument for operations that need two pieces\nof info, sometimes the first one is assumed to be missing and gets\nthe default, some other times the second one is assumed to be\nmissing and gets the default\" design, which I felt would be\nunnecessarily confusing.\n\nThe issue of possible confusion you raised is real, was discussed in\nthe main thread of discussion of the earlier round, and has been\naddressed in this round of the patch series, I think, with warnings\nand/or advises.\n"}]}