{"thread":{"id":"46452","subject":"[PATCH/RFC] branch: warn user about non-existent branch","startedAt":"2017-07-24T15:41:19Z","lastAt":"2018-03-24T17:10:08Z","messageCount":127,"participants":["Kaartic Sivaraam","Junio C Hamano","Martin Ågren","Stefan Beller","Eric Sunshine","Kevin Daudt","SZEDER Gábor"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"324950","messageId":"20170724154119.2926-1-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":null,"subject":"[PATCH/RFC] branch: warn user about non-existent branch","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-24T15:41:19Z","receivedAt":"2017-07-24T15:41:19Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The inexistence of the branch trying to be renamed wasn't checked\nand was left for 'rename_ref' to point out. It's better to do it\nexplicitly as it leads to unconventional behaviour in the following\ncase,\n\n $ git branch -m foo master\n fatal: A branch named 'master' already exists.\n\nIt's conventional to report that the 'foo' doesn't exist rather than\nrepoting that 'master' exists, the same way the 'mv' command does.\n\n $ mv foo existing_file\n mv: cannot stat 'foo': No such file or directory\n\nFurther, there's no way for 'master' being overwritten with 'foo',\nas it doesn't exist. Reporting the existence of 'master' is germane\nonly when 'master' is *really* going to be overwritten.\n\nSo, report the inexistence of the branch explicitly before reporting\nexistence of new branch name to be consistent with it's counterpart,\nthe widely used, the 'mv' command.\n\nSigned-off-by: Kaartic Sivaraam \n---\n I'm sending this patch as I didn't want to leave this thread\n open ended. I'm not yet sure if this is a good thing to do.\n This patch is open to comments, as the prvious ones I've sent\n have been.\n\n builtin/branch.c | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex a3bd2262b..0a9112335 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -473,6 +473,10 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t\t\tdie(_(\"Invalid branch name: '%s'\"), oldname);\n \t}\n \n+\t/* Check for existence of oldref before proceeding */\n+\tif(!ref_exists(oldref.buf))\n+\t\tdie(_(\"Branch '%s' does not exist.\"), oldname);\n+\n \t/*\n \t * A command like \"git branch -M currentbranch currentbranch\" cannot\n \t * cause the worktree to become inconsistent with HEAD, so allow it.\n-- \n2.13.2.23.g14d9f4c6d\n\n"},{"id":"324973","messageId":"1500923812.20078.8.camel@gmail.com","threadId":"46452","inReplyTo":"20170724154119.2926-1-kaarticsivaraam91196@gmail.com","subject":"Change in output as a result of patch","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-24T19:16:52Z","receivedAt":"2017-07-24T19:17:42Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The patch in the previous mail results in a change in output as\nspecified below.\n\n $ git branch\n * master\n   foo\n   bar\n\nBefore patch,\n\n $ git branch -m hypothet master\n fatal: A branch named 'master' already exists.\n\n $ git branch -m hypothet real\n error: refname refs/heads/hypothet not found\n fatal: Branch rename failed\n\nAfter patch,\n\n $ git branch -m hypothet master\n fatal: Branch 'hypothet' does not exist.\n\n $ git branch -m hypothet real\n fatal: Branch 'hypothet' does not exist.\n\n-- \nKaartic\n"},{"id":"325001","messageId":"xmqqd18pcysa.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"1500923812.20078.8.camel@gmail.com","subject":"Re: Change in output as a result of patch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-24T21:25:57Z","receivedAt":"2017-07-24T21:26:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> The patch in the previous mail results in a change in output as\n> specified below.\n>\n> $ git branch\n> * master\n> foo\n> bar\n>\n> Before patch,\n>\n> $ git branch -m hypothet master\n> fatal: A branch named 'master' already exists.\n>\n> $ git branch -m hypothet real\n> error: refname refs/heads/hypothet not found\n> fatal: Branch rename failed\n>\n> After patch,\n>\n> $ git branch -m hypothet master\n> fatal: Branch 'hypothet' does not exist.\n>\n> $ git branch -m hypothet real\n> fatal: Branch 'hypothet' does not exist.\n\nImagine this scenario instead, which I think is more realistic\nexample of making a typo. The set of existing branches are like\nthis:\n\n $ git branch\n devel\n * test\n\nAnd then you get these with your patch:\n\n $ git branch -m tets devel\n fatal: Branch 'tets' does not exist.\n\n $ git branch -m test devel\n fatal: A branch named 'devel' already exists.\n\nMy reaction to the above exchange would be a moderately strong\nannoyance. If I were told that I am using 'devel' for something\nelse already, my \"corrected\" attempt to turn the 'test' branch to a\nreal development branch after getting the first error would have\nbeen:\n\n $ git branch -m test devel2\n\nand I didn't have to get the second error.\n\nI think your patch points in the right direction---if an operation\ncan fail due to two reasons, reordering the two checks and still\nfail with a report for just the first one you happened to check\nfirst does not give us a real improvement. If it is easy to check\nthe other one after you noticed one of the condition is violated,\nthen you could give a more useful diagnosis, namely, \"There is\nbranch 'tets' to rename, and there already is 'devel' branch\".\n\nI suspect that with a moderately-sized refactoring around\nvalidate_new_branchname() function, this should be doable. Instead\nof passing two \"int\" parameters force and attr_only, make them into\na single \"unsigned flag\" and allow the caller to pass another option\nto tell the function \"do not die, do not issue a message, but tell\nthe caller what is wrong with a return value\". And by using that\nupdated API, rename_branch() could tell four cases apart and fail\nthe three bad cases in a more sensible way.\n\nIn any case, the illustrations of interaction before and after the\nchange is a very good thing to have when discussing a patch, and you\nare encouraged to put them in your proposed log message.\n\n\n\n"},{"id":"325055","messageId":"1501008842.11979.7.camel@gmail.com","threadId":"46452","inReplyTo":"xmqqd18pcysa.fsf@gitster.mtv.corp.google.com","subject":"Re: Change in output as a result of patch","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-25T18:54:02Z","receivedAt":"2017-07-25T18:53:43Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Let me see if I got everything correctly. Correct me if any of the\nbelow observations are wrong.\n\nOn Mon, 2017-07-24 at 14:25 -0700, Junio C Hamano wrote:\n> Imagine this scenario instead, which I think is more realistic\n> example of making a typo. The set of existing branches are like\n> this:\n> \n> $ git branch\n> devel\n> * test\n> \n> And then you get these with your patch:\n> \n> $ git branch -m tets devel\n> fatal: Branch 'tets' does not exist.\n> \n> $ git branch -m test devel\n> fatal: A branch named 'devel' already exists.\n> \n> My reaction to the above exchange would be a moderately strong\n> annoyance. If I were told that I am using 'devel' for something\n> else already, my \"corrected\" attempt to turn the 'test' branch to a\n> real development branch after getting the first error would have\n> been:\n> \n> $ git branch -m test devel2\n> \n> and I didn't have to get the second error.\n> \n> I think your patch points in the right direction---if an operation\n> can fail due to two reasons, reordering the two checks and still\n> fail with a report for just the first one you happened to check\n> first does not give us a real improvement. If it is easy to check\n> the other one after you noticed one of the condition is violated,\n> then you could give a more useful diagnosis, namely, \"There is\n> branch 'tets' to rename, and there already is 'devel' branch\".\n> \nSo what's expected is an error message that details all possible errors\nfound in a command in a single message. Now that would be better than\nwhat 'mv' does.\n\n> I suspect that with a moderately-sized refactoring around\n> validate_new_branchname() function, this should be doable. Instead\n> of passing two \"int\" parameters force and attr_only, make them into\n> a single \"unsigned flag\" and allow the caller to pass another option\n> to tell the function \"do not die, do not issue a message, but tell\n> the caller what is wrong with a return value\". And by using that\n> updated API, rename_branch() could tell four cases apart and fail\n> the three bad cases in a more sensible way.\n> \nOk, now that seems to require little work. I'll see what I could come\nup with.\n\nBefore I get into this I noticed that \"--set-upstream\" has been\ndeprecated since,\n\nb347d06bf09 (branch: deprecate --set-upstream and show help if we detect possible mistaken use,\n Thu Aug 30 19:23:13 2012)\n\nIs there any possibility for it to be removed some time in the near\nfuture?\n\nI'm asking this because IIRC, the 'attr_only' parameter of\n\"validate_new_branchname\" was introduced to fix a regression\n(fa7993767560) caused by the \"--set-upstream\" option. In case it has\nbeen planned to be removed some time soon, it could make the word\neasier (?), not sure though.\n\n> In any case, the illustrations of interaction before and after the\n> change is a very good thing to have when discussing a patch,\nI would like to credit that to \"Ævar Arnfjörð Bjarmason\", who suggested\nthat to me in one of the other threads.\n\n-- \nKaartic\n"},{"id":"325159","messageId":"xmqq1sp2q1cc.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"1501008842.11979.7.camel@gmail.com","subject":"Re: Change in output as a result of patch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-26T22:29:07Z","receivedAt":"2017-07-26T22:29:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> b347d06bf09 (branch: deprecate --set-upstream and show help if we detect possible mistaken use,\n> Thu Aug 30 19:23:13 2012)\n>\n> Is there any possibility for it to be removed some time in the near\n> future?\n>\n> I'm asking this because IIRC, the 'attr_only' parameter of\n> \"validate_new_branchname\" was introduced to fix a regression\n> (fa7993767560) caused by the \"--set-upstream\" option. In case it has\n> been planned to be removed some time soon, it could make the word\n> easier (?), not sure though.\n\nI suspect that it would not make the refactoring that much less\nwork, but you are right---it is about time we started looking into\nremoving the --set-upstream optin whose 5th anniversary after\ndeprecation is only one month away.\n\n"},{"id":"325685","messageId":"20170807143938.5127-1-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"xmqq1sp2q1cc.fsf@gitster.mtv.corp.google.com","subject":"Can the '--set-upstream' option of branch be removed ?","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-07T14:39:36Z","receivedAt":"2017-08-07T14:39:40Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"\nI refactored builtin/branch.c to remove the '--set-upstream'\noption,successfully. The corresponding patch follows. \n\nThere's just one issue with the version of git that doesn't\nhave the '--set-upstream' option. It's described in the commit\nlog message of the following patch.\n\nI guess it would be difficult to detect the removal of the option in\ncase it's used in scripts and might cause confusion to users?\nIs it ok to proceed with the removal?\n\nBTW, It's now clear to me that removing '--set-upstream' has nothing\nto do with merging the two parameter of 'validate_new_branchname'.\n\n-- \nKaartic\n"},{"id":"325686","messageId":"20170807143938.5127-2-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170807143938.5127-1-kaarticsivaraam91196@gmail.com","subject":"[PATCH 1/2 / RFC] builtin/branch: remove the deprecated '--set-upstream' option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-07T14:39:37Z","receivedAt":"2017-08-07T14:39:45Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The '--set-upstream' option of branch was deprecated in,\n\n b347d06bf branch: deprecate --set-upstream and show help if we detect\n possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)\n\nIt was deprecated for the reasons specified in the commit message of\nthe referenced commit.\n\nRefactor 'branch' so that it doesn't accept '--set-upstream'.\n\nNote that, 'git branch' still *accepts* '--set-upstream' as a consequence\nof \"unique prefix can be abbrievated in option names\". '--set-upstream'\nis a unique prefix of '--set-upstream-to' after '--set-upstream' has\nbeen removed.\n\nThe before/after behaviour for a simple case follows,\n\n $ git remote\n origin\n\nBefore,\n\n $ git branch\n * master\n\n $ git branch --set-upstream origin/master\n The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\n Branch origin/master set up to track local branch master.\n\n $ git branch\n * master\n origin/master\n\nAfter,\n\n $ git branch\n * master\n\n $ git branch --set-upstream origin/master\n Branch master set up to track remote branch master from origin.\n\n $ git branch\n * master\n\nNote that the option used in the after sequence is still '--set-upstream'\nthough the behaviour is that of '--set-upstream-to'.\n\nSigned-off-by: Kaartic Sivaraam \n---\n Documentation/git-branch.txt | 10 ++-------\n builtin/branch.c | 24 ---------------------\n t/t3200-branch.sh | 50 ++------------------------------------------\n 3 files changed, 4 insertions(+), 80 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 81bd0a7b7..23c47b850 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -14,7 +14,7 @@ SYNOPSIS\n \t[(--merged | --no-merged) []]\n \t[--contains []]\n \t[--points-at ] [--format=] [...]\n-'git branch' [--set-upstream | --track | --no-track] [-l] [-f] []\n+'git branch' [--track | --no-track] [-l] [-f] []\n 'git branch' (--set-upstream-to= | -u ) []\n 'git branch' --unset-upstream []\n 'git branch' (-m | -M) [] \n@@ -81,7 +81,7 @@ OPTIONS\n --delete::\n \tDelete a branch. The branch must be fully merged in its\n \tupstream branch, or in `HEAD` if no upstream was set with\n-\t`--track` or `--set-upstream`.\n+\t`--track` or `--set-upstream-to`.\n \n -D::\n \tShortcut for `--delete --force`.\n@@ -194,12 +194,6 @@ start-point is either a local or remote-tracking branch.\n \tDo not set up \"upstream\" configuration, even if the\n \tbranch.autoSetupMerge configuration variable is true.\n \n---set-upstream::\n-\tIf specified branch does not exist yet or if `--force` has been\n-\tgiven, acts exactly like `--track`. Otherwise sets up configuration\n-\tlike `--track` would when creating the branch, except that where\n-\tbranch points to is not changed.\n-\n -u ::\n --set-upstream-to=::\n \tSet up 's tracking information so is\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex a3bd2262b..a70fa8bc6 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -557,8 +557,6 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tOPT__QUIET(&quiet, N_(\"suppress informational messages\")),\n \t\tOPT_SET_INT('t', \"track\", &track, N_(\"set up tracking mode (see git-pull(1))\"),\n \t\t\tBRANCH_TRACK_EXPLICIT),\n-\t\tOPT_SET_INT( 0, \"set-upstream\", &track, N_(\"change upstream info\"),\n-\t\t\tBRANCH_TRACK_OVERRIDE),\n \t\tOPT_STRING('u', \"set-upstream-to\", &new_upstream, N_(\"upstream\"), N_(\"change the upstream info\")),\n \t\tOPT_BOOL(0, \"unset-upstream\", &unset_upstream, N_(\"Unset the upstream info\")),\n \t\tOPT__COLOR(&branch_use_color, N_(\"use colored output\")),\n@@ -755,8 +753,6 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tstrbuf_release(&buf);\n \t} else if (argc > 0 && argc <= 2) {\n \t\tstruct branch *branch = branch_get(argv[0]);\n-\t\tint branch_existed = 0, remote_tracking = 0;\n-\t\tstruct strbuf buf = STRBUF_INIT;\n \n \t\tif (!strcmp(argv[0], \"HEAD\"))\n \t\t\tdie(_(\"it does not make sense to create 'HEAD' manually\"));\n@@ -767,29 +763,9 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tif (filter.kind != FILTER_REFS_BRANCHES)\n \t\t\tdie(_(\"-a and -r options to 'git branch' do not make sense with a branch name\"));\n \n-\t\tif (track == BRANCH_TRACK_OVERRIDE)\n-\t\t\tfprintf(stderr, _(\"The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\\n\"));\n-\n-\t\tstrbuf_addf(&buf, \"refs/remotes/%s\", branch->name);\n-\t\tremote_tracking = ref_exists(buf.buf);\n-\t\tstrbuf_release(&buf);\n-\n-\t\tbranch_existed = ref_exists(branch->refname);\n \t\tcreate_branch(argv[0], (argc == 2) ? argv[1] : head,\n \t\t\t force, reflog, 0, quiet, track);\n \n-\t\t/*\n-\t\t * We only show the instructions if the user gave us\n-\t\t * one branch which doesn't exist locally, but is the\n-\t\t * name of a remote-tracking branch.\n-\t\t */\n-\t\tif (argc == 1 && track == BRANCH_TRACK_OVERRIDE &&\n-\t\t !branch_existed && remote_tracking) {\n-\t\t\tfprintf(stderr, _(\"\\nIf you wanted to make '%s' track '%s', do this:\\n\\n\"), head, branch->name);\n-\t\t\tfprintf(stderr, \" git branch -d %s\\n\", branch->name);\n-\t\t\tfprintf(stderr, \" git branch --set-upstream-to %s\\n\", branch->name);\n-\t\t}\n-\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 dd37ac47c..3ae87c238 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -561,7 +561,8 @@ test_expect_success 'use --set-upstream-to modify a particular branch' '\n \tgit branch my13 &&\n \tgit branch --set-upstream-to master my13 &&\n \ttest \"$(git config branch.my13.remote)\" = \".\" &&\n-\ttest \"$(git config branch.my13.merge)\" = \"refs/heads/master\"\n+\ttest \"$(git config branch.my13.merge)\" = \"refs/heads/master\" &&\n+\tgit branch --unset-upstream my13\n '\n \n test_expect_success '--unset-upstream should fail if given a non-existent branch' '\n@@ -605,40 +606,6 @@ test_expect_success 'test --unset-upstream on a particular branch' '\n \ttest_must_fail git config branch.my14.merge\n '\n \n-test_expect_success '--set-upstream shows message when creating a new branch that exists as remote-tracking' '\n-\tgit update-ref refs/remotes/origin/master HEAD &&\n-\tgit branch --set-upstream origin/master 2>actual &&\n-\ttest_when_finished git update-ref -d refs/remotes/origin/master &&\n-\ttest_when_finished git branch -d origin/master &&\n-\tcat >expected <actual &&\n-\ttest_when_finished git branch --unset-upstream master &&\n-\tcat >expected <actual &&\n-\ttest_when_finished git branch --unset-upstream my13 &&\n-\tcat >expected <actual &&\n \tcat >expected <<-\\EOF &&\n@@ -961,19 +928,6 @@ test_expect_success 'attempt to delete a branch merged to its base' '\n \ttest_must_fail git branch -d my10\n '\n \n-test_expect_success 'use set-upstream on the current branch' '\n-\tgit checkout master &&\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 branch --set-upstream master origin/frotz &&\n-\n-\ttest \"z$(git config branch.master.remote)\" = \"zorigin\" &&\n-\ttest \"z$(git config branch.master.merge)\" = \"zrefs/heads/frotz\"\n-\n-'\n-\n test_expect_success 'use --edit-description' '\n \twrite_script editor <<-\\EOF &&\n \t\techo \"New contents\" >\"$1\"\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"325687","messageId":"20170807143938.5127-3-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170807143938.5127-1-kaarticsivaraam91196@gmail.com","subject":"[PATCH 2/2 / RFC] branch: quote branch/ref names to improve readability","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-07T14:39:38Z","receivedAt":"2017-08-07T14:39:51Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Signed-off-by: Kaartic Sivaraam \n---\n branch.c | 16 ++++++++--------\n 1 file changed, 8 insertions(+), 8 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex ad5a2299b..a40721f3c 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -90,24 +90,24 @@ int install_branch_config(int flag, const char *local, const char *origin, const\n \t\tif (shortname) {\n \t\t\tif (origin)\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track remote branch %s from %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track remote branch %s from %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote branch '%s' from '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote branch '%s' from '%s'.\"),\n \t\t\t\t\t local, shortname, origin);\n \t\t\telse\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track local branch %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track local branch %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track local branch '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track local branch '%s'.\"),\n \t\t\t\t\t local, shortname);\n \t\t} else {\n \t\t\tif (origin)\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track remote ref %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track remote ref %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote ref '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote ref '%s'.\"),\n \t\t\t\t\t local, remote);\n \t\t\telse\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track local ref %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track local ref %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track local ref '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track local ref '%s'.\"),\n \t\t\t\t\t local, remote);\n \t\t}\n \t}\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"325689","messageId":"1502117376.5314.2.camel@gmail.com","threadId":"46452","inReplyTo":"xmqqd18pcysa.fsf@gitster.mtv.corp.google.com","subject":"Re: Change in output as a result of patch","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-07T14:49:36Z","receivedAt":"2017-08-07T14:49:09Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Mon, 2017-07-24 at 14:25 -0700, Junio C Hamano wrote:\n> I suspect that with a moderately-sized refactoring around\n> validate_new_branchname() function, this should be doable. Instead\n> of passing two \"int\" parameters force and attr_only, make them into\n> a single \"unsigned flag\"\nI guess it's not possible to merge the two parameters into one as the\nfollowing code path shouldn't be taken when 'attr_only' is set,\n\n if (!attr_only) {\n \t const char *head;\n \t struct object_id oid;\n\n \t head = resolve_ref_unsafe(\"HEAD\", 0, oid.hash, NULL);\n \t if (!is_bare_repository() && head && !strcmp(head, ref->buf))\n \t \t die(_(\"Cannot force update the current branch.\"));\n }\n\nand I guess this means the 'attr_only' can't merged with 'force'.\n\nFurther, I saw this in 'branch.h'\n\n> NEEDSWORK: This needs to be split into two separate functions in the\n> longer run for sanity.\n\nAny ways in which I could help with this?\n\n-- \nKaartic\n"},{"id":"325742","messageId":"xmqq60dzp00l.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"20170807143938.5127-1-kaarticsivaraam91196@gmail.com","subject":"Re: Can the '--set-upstream' option of branch be removed ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-07T20:59:22Z","receivedAt":"2017-08-07T20:59:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> I refactored builtin/branch.c to remove the '--set-upstream'\n> option,successfully. The corresponding patch follows. \n>\n> There's just one issue with the version of git that doesn't\n> have the '--set-upstream' option. It's described in the commit\n> log message of the following patch.\n\nwhich is...\n\n> Note that, 'git branch' still *accepts* '--set-upstream' as a consequence\n> of \"unique prefix can be abbrievated in option names\". '--set-upstream'\n> is a unique prefix of '--set-upstream-to' after '--set-upstream' has\n> been removed.\n\n... this.\n\nThanks for spotting the issue. \n\nI think in the longer term we still want to remove --set-upstream as\nmany people seem to say that its behaviour has been uttering\nconfusing to them and that is why we keep giving the warning any\ntime it is used.\n\n> I guess it would be difficult to detect the removal of the option in\n> case it's used in scripts and might cause confusion to users?\n\nIf we want to follow through the transition, because of the issue\nyou spotted, we'd need one extra step to make sure users won't be\nhurt before removal: we would need to still recognize --set-upstream\nas an option distinct from --set-upstream-to, and actively fail the\nrequest, telling them that the former option no longer is supported.\n\nThen after waiting for a few years, we may be able to re-introduce\nthe \"--set-upstream\" option that takes the arguments in the same\norder as \"--set-upstream-to\", which would be the ideal endgame\n(assuming that the reason why we started deprecating \"--set-upstream\"\nand encouraged users to use \"--set-upstream-to\" still holds).\n\n"},{"id":"325804","messageId":"1502197230.2071.3.camel@gmail.com","threadId":"46452","inReplyTo":"xmqq60dzp00l.fsf@gitster.mtv.corp.google.com","subject":"Re: Can the '--set-upstream' option of branch be removed ?","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-08T13:00:30Z","receivedAt":"2017-08-08T13:00:04Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Mon, 2017-08-07 at 13:59 -0700, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n> \n> > I refactored builtin/branch.c to remove the '--set-upstream'\n> > option,successfully. The corresponding patch follows. \n> > \n> > There's just one issue with the version of git that doesn't\n> > have the '--set-upstream' option. It's described in the commit\n> > log message of the following patch.\n> \n> which is...\n> \n> > Note that, 'git branch' still *accepts* '--set-upstream' as a consequence\n> > of \"unique prefix can be abbrievated in option names\". '--set-upstream'\n> > is a unique prefix of '--set-upstream-to' after '--set-upstream' has\n> > been removed.\n> \n> ... this.\n> \n> Thanks for spotting the issue. \n> \nOh, I would have to thank you for enlightening me about,\n\n \"unique prefix can be abbrievated in option names\"\n\nIf I didn't know that, it would taken me some time (or an email) to\nfind why 'git' accepted '--set-upstream' even after it's removal!\n\n> I think in the longer term we still want to remove --set-upstream as\n> many people seem to say that its behaviour has been uttering\n> confusing to them and that is why we keep giving the warning any\n> time it is used.\n> \nI do accept that. The behaviour of '--set-upstream' is awkward.\n\n> > I guess it would be difficult to detect the removal of the option in\n> > case it's used in scripts and might cause confusion to users?\n> \n> If we want to follow through the transition, because of the issue\n> you spotted, we'd need one extra step to make sure users won't be\n> hurt before removal: we would need to still recognize --set-upstream\n> as an option distinct from --set-upstream-to, and actively fail thes\n> request, telling them that the former option no longer is supported.\n> \nThere's no issue in doing that if people don't shout at us for the\nbehaviour :)\n\nJust to be sure, you mean \"die() with a good message\" when you say\n\"fail these requests, telling them that the former option no longer is\nsupported.\"\n\n> Then after waiting for a few years, we may be able to re-introduce\n> the \"--set-upstream\" option that takes the arguments in the same\n> order as \"--set-upstream-to\", which would be the ideal endgame\n> (assuming that the reason why we started deprecating \"--set-upstream\"\n> and encouraged users to use \"--set-upstream-to\" still holds).\n> \nIt's pretty surprising it takes almost a decade to *stop accepting* a\nbad option though many users are confused by it. \n\n\"It's easier to do things than to undo them!\"\n\n-- \nKaartic\n"},{"id":"325812","messageId":"xmqqo9rqc8ha.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"1502197230.2071.3.camel@gmail.com","subject":"Re: Can the '--set-upstream' option of branch be removed ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-08T16:47:13Z","receivedAt":"2017-08-08T16:47:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> Just to be sure, you mean \"die() with a good message\" when you say\n> \"fail these requests, telling them that the former option no longer is\n> supported.\"\n\nYes.\n\n> It's pretty surprising it takes almost a decade to *stop accepting* a\n> bad option though many users are confused by it.\n>\n> \"It's easier to do things than to undo them!\"\n\nYes, that is why we try to be extra cautious when adding new things.\n"},{"id":"325817","messageId":"20170808171136.31168-1-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"xmqq60dzp00l.fsf@gitster.mtv.corp.google.com","subject":"[PATCH v2 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-08T17:11:35Z","receivedAt":"2017-08-08T17:11:31Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The '--set-upstream' option of branch was deprecated in,\n\n b347d06bf branch: deprecate --set-upstream and show help if we\n detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)\n\nIt was deprecated for the reasons specified in the commit message of\nthe referenced commit.\n\nRefactor 'branch' so that it dies with an appropraite error message\nwhen the '--set-upstream' is used.\n\nNote that there's a reason behind \"dying with an error message\" instead of\n\"not accepting the '--set-upstream'\". ;git branch' would still *accept*\n'--set-upstream' even after it's removal as a consequence of \"unique\nprefix can be abbrievated in option names\" AND '--set-upstream' is a unique\nprefix of '--set-upstream-to' when '--set-upstream' has been removed. In\norder to smooth the transition for users due to the \"prefix issue\" it was\ndecided to make branch die when seeing the '--set-upstream' flag for a few\nyears and let the users know that it would be removed some time in the future.\n\nThe before/after behaviour for a simple case follows,\n\n $ git remote\n origin\n\nBefore,\n\n $ git branch\n * master\n\n $ git branch --set-upstream origin/master\n The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\n Branch origin/master set up to track local branch master.\n\n $ echo $?\n 0\n\n $ git branch\n * master\n origin/master\n\nAfter,\n\n $ git branch\n * master\n\n $ git branch --set-upstream origin/master\n fatal: the '--set-upstream' flag is no longer supported and will be removed. Consider using '--track' or '--set-upstream-to'\n\n $ echo $?\n 128\n\n $ git branch\n * master\n\nSigned-off-by: Kaartic Sivaraam \n---\n Changes in v2:\n\n The previous patch removed the concerned option while the current patch\n makes 'git branch' die on seeing the option.\n\n The possibility of '--set-upstream' becoming an alias of '--set-upstream-to'\n was documented.\n\n Documentation/git-branch.txt | 8 +++----\n builtin/branch.c | 21 +------------------\n t/t3200-branch.sh | 50 ++++----------------------------------------\n t/t6040-tracking-info.sh | 16 +++++++-------\n 4 files changed, 17 insertions(+), 78 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 81bd0a7b7..372107e0c 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -195,10 +195,10 @@ start-point is either a local or remote-tracking branch.\n \tbranch.autoSetupMerge configuration variable is true.\n \n --set-upstream::\n-\tIf specified branch does not exist yet or if `--force` has been\n-\tgiven, acts exactly like `--track`. Otherwise sets up configuration\n-\tlike `--track` would when creating the branch, except that where\n-\tbranch points to is not changed.\n+\tThis option is no longer supported and will be removed in the future.\n+\tConsider using --track or --set-upstream-to instead.\n++\n+Note: This could possibly become an alias of --set-upstream-to in the future.\n \n -u ::\n --set-upstream-to=::\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex a3bd2262b..2fcb6f7e5 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -755,8 +755,6 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tstrbuf_release(&buf);\n \t} else if (argc > 0 && argc <= 2) {\n \t\tstruct branch *branch = branch_get(argv[0]);\n-\t\tint branch_existed = 0, remote_tracking = 0;\n-\t\tstruct strbuf buf = STRBUF_INIT;\n \n \t\tif (!strcmp(argv[0], \"HEAD\"))\n \t\t\tdie(_(\"it does not make sense to create 'HEAD' manually\"));\n@@ -768,28 +766,11 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tdie(_(\"-a and -r options to 'git branch' do not make sense with a branch name\"));\n \n \t\tif (track == BRANCH_TRACK_OVERRIDE)\n-\t\t\tfprintf(stderr, _(\"The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\\n\"));\n+\t\t\tdie(_(\"the '--set-upstream' flag is no longer supported and will be removed. Consider using '--track' or '--set-upstream-to'\"));\n \n-\t\tstrbuf_addf(&buf, \"refs/remotes/%s\", branch->name);\n-\t\tremote_tracking = ref_exists(buf.buf);\n-\t\tstrbuf_release(&buf);\n-\n-\t\tbranch_existed = ref_exists(branch->refname);\n \t\tcreate_branch(argv[0], (argc == 2) ? argv[1] : head,\n \t\t\t force, reflog, 0, quiet, track);\n \n-\t\t/*\n-\t\t * We only show the instructions if the user gave us\n-\t\t * one branch which doesn't exist locally, but is the\n-\t\t * name of a remote-tracking branch.\n-\t\t */\n-\t\tif (argc == 1 && track == BRANCH_TRACK_OVERRIDE &&\n-\t\t !branch_existed && remote_tracking) {\n-\t\t\tfprintf(stderr, _(\"\\nIf you wanted to make '%s' track '%s', do this:\\n\\n\"), head, branch->name);\n-\t\t\tfprintf(stderr, \" git branch -d %s\\n\", branch->name);\n-\t\t\tfprintf(stderr, \" git branch --set-upstream-to %s\\n\", branch->name);\n-\t\t}\n-\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 dd37ac47c..249be4b1a 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -561,7 +561,8 @@ test_expect_success 'use --set-upstream-to modify a particular branch' '\n \tgit branch my13 &&\n \tgit branch --set-upstream-to master my13 &&\n \ttest \"$(git config branch.my13.remote)\" = \".\" &&\n-\ttest \"$(git config branch.my13.merge)\" = \"refs/heads/master\"\n+\ttest \"$(git config branch.my13.merge)\" = \"refs/heads/master\" &&\n+\tgit branch --unset-upstream my13\n '\n \n test_expect_success '--unset-upstream should fail if given a non-existent branch' '\n@@ -605,38 +606,8 @@ test_expect_success 'test --unset-upstream on a particular branch' '\n \ttest_must_fail git config branch.my14.merge\n '\n \n-test_expect_success '--set-upstream shows message when creating a new branch that exists as remote-tracking' '\n-\tgit update-ref refs/remotes/origin/master HEAD &&\n-\tgit branch --set-upstream origin/master 2>actual &&\n-\ttest_when_finished git update-ref -d refs/remotes/origin/master &&\n-\ttest_when_finished git branch -d origin/master &&\n-\tcat >expected <actual &&\n-\ttest_when_finished git branch --unset-upstream master &&\n-\tcat >expected <actual &&\n-\ttest_when_finished git branch --unset-upstream my13 &&\n-\tcat >expected <\"$1\"\ndiff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh\nindex 97a07655a..4b522f456 100755\n--- a/t/t6040-tracking-info.sh\n+++ b/t/t6040-tracking-info.sh\n@@ -188,35 +188,35 @@ test_expect_success 'fail to track annotated tags' '\n \ttest_must_fail git checkout heavytrack\n '\n \n-test_expect_success 'setup tracking with branch --set-upstream on existing branch' '\n+test_expect_success 'setup tracking with branch --set-upstream-to on existing branch' '\n \tgit branch from-master master &&\n \ttest_must_fail git config branch.from-master.merge > actual &&\n-\tgit branch --set-upstream from-master master &&\n+\tgit branch --set-upstream-to master from-master &&\n \tgit config branch.from-master.merge > actual &&\n \tgrep -q \"^refs/heads/master$\" actual\n '\n \n-test_expect_success '--set-upstream does not change branch' '\n+test_expect_success '--set-upstream-to does not change branch' '\n \tgit branch from-master2 master &&\n \ttest_must_fail git config branch.from-master2.merge > actual &&\n \tgit rev-list from-master2 &&\n \tgit update-ref refs/heads/from-master2 from-master2^ &&\n \tgit rev-parse from-master2 >expect2 &&\n-\tgit branch --set-upstream from-master2 master &&\n+\tgit branch --set-upstream-to master from-master2 &&\n \tgit config branch.from-master.merge > actual &&\n \tgit rev-parse from-master2 >actual2 &&\n \tgrep -q \"^refs/heads/master$\" actual &&\n \tcmp expect2 actual2\n '\n \n-test_expect_success '--set-upstream @{-1}' '\n-\tgit checkout from-master &&\n+test_expect_success '--set-upstream-to @{-1}' '\n+\tgit checkout follower &&\n \tgit checkout from-master2 &&\n \tgit config branch.from-master2.merge > expect2 &&\n-\tgit branch --set-upstream @{-1} follower &&\n+\tgit branch --set-upstream-to @{-1} from-master &&\n \tgit config branch.from-master.merge > actual &&\n \tgit config branch.from-master2.merge > actual2 &&\n-\tgit branch --set-upstream from-master follower &&\n+\tgit branch --set-upstream-to follower from-master &&\n \tgit config branch.from-master.merge > expect &&\n \ttest_cmp expect2 actual2 &&\n \ttest_cmp expect actual\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"325818","messageId":"20170808171136.31168-2-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170808171136.31168-1-kaarticsivaraam91196@gmail.com","subject":"[PATCH v2 2/2 / RFC] branch: quote branch/ref names to improve readability","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-08T17:11:36Z","receivedAt":"2017-08-08T17:11:33Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Signed-off-by: Kaartic Sivaraam \n---\n branch.c | 16 ++++++++--------\n 1 file changed, 8 insertions(+), 8 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex ad5a2299b..a40721f3c 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -90,24 +90,24 @@ int install_branch_config(int flag, const char *local, const char *origin, const\n \t\tif (shortname) {\n \t\t\tif (origin)\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track remote branch %s from %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track remote branch %s from %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote branch '%s' from '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote branch '%s' from '%s'.\"),\n \t\t\t\t\t local, shortname, origin);\n \t\t\telse\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track local branch %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track local branch %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track local branch '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track local branch '%s'.\"),\n \t\t\t\t\t local, shortname);\n \t\t} else {\n \t\t\tif (origin)\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track remote ref %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track remote ref %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote ref '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote ref '%s'.\"),\n \t\t\t\t\t local, remote);\n \t\t\telse\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track local ref %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track local ref %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track local ref '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track local ref '%s'.\"),\n \t\t\t\t\t local, remote);\n \t\t}\n \t}\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"325827","messageId":"CAN0heSqbAdYy-2c0CfO2OxijtvncGWe432bFmkpHZugKDrx-pw@mail.gmail.com","threadId":"46452","inReplyTo":"20170808171136.31168-1-kaarticsivaraam91196@gmail.com","subject":"Re: [PATCH v2 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Martin Ågren","fromEmail":"martin.agren@gmail.com","sentAt":"2017-08-08T18:33:26Z","receivedAt":"2017-08-08T18:33:31Z","isPatch":true,"sender":{"key":"martin.agren@gmail.com","avatar":null},"body":"On 8 August 2017 at 19:11, Kaartic Sivaraam\n wrote:\n> The '--set-upstream' option of branch was deprecated in,\n>\n> b347d06bf branch: deprecate --set-upstream and show help if we\n> detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)\n>\n> It was deprecated for the reasons specified in the commit message of\n> the referenced commit.\n>\n> Refactor 'branch' so that it dies with an appropraite error message\n> when the '--set-upstream' is used.\n\nappropriate. (Also, is this really a refactoring?)\n\n>\n> Note that there's a reason behind \"dying with an error message\" instead of\n> \"not accepting the '--set-upstream'\". ;git branch' would still *accept*\n> '--set-upstream' even after it's removal as a consequence of \"unique\n> prefix can be abbrievated in option names\" AND '--set-upstream' is a unique\n> prefix of '--set-upstream-to' when '--set-upstream' has been removed. In\n> order to smooth the transition for users due to the \"prefix issue\" it was\n> decided to make branch die when seeing the '--set-upstream' flag for a few\n> years and let the users know that it would be removed some time in the future.\n>\n> The before/after behaviour for a simple case follows,\n>\n> $ git remote\n> origin\n>\n> Before,\n>\n> $ git branch\n> * master\n>\n> $ git branch --set-upstream origin/master\n> The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\n> Branch origin/master set up to track local branch master.\n>\n> $ echo $?\n> 0\n>\n> $ git branch\n> * master\n> origin/master\n>\n> After,\n>\n> $ git branch\n> * master\n>\n> $ git branch --set-upstream origin/master\n> fatal: the '--set-upstream' flag is no longer supported and will be removed. Consider using '--track' or '--set-upstream-to'\n>\n> $ echo $?\n> 128\n>\n> $ git branch\n> * master\n>\n> Signed-off-by: Kaartic Sivaraam \n> ---\n> Changes in v2:\n>\n> The previous patch removed the concerned option while the current patch\n> makes 'git branch' die on seeing the option.\n>\n> The possibility of '--set-upstream' becoming an alias of '--set-upstream-to'\n> was documented.\n>\n> Documentation/git-branch.txt | 8 +++----\n> builtin/branch.c | 21 +------------------\n> t/t3200-branch.sh | 50 ++++----------------------------------------\n> t/t6040-tracking-info.sh | 16 +++++++-------\n> 4 files changed, 17 insertions(+), 78 deletions(-)\n>\n> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\n> index 81bd0a7b7..372107e0c 100644\n> --- a/Documentation/git-branch.txt\n> +++ b/Documentation/git-branch.txt\n> @@ -195,10 +195,10 @@ start-point is either a local or remote-tracking branch.\n> branch.autoSetupMerge configuration variable is true.\n>\n> --set-upstream::\n> - If specified branch does not exist yet or if `--force` has been\n> - given, acts exactly like `--track`. Otherwise sets up configuration\n> - like `--track` would when creating the branch, except that where\n> - branch points to is not changed.\n> + This option is no longer supported and will be removed in the future.\n> + Consider using --track or --set-upstream-to instead.\n> ++\n> +Note: This could possibly become an alias of --set-upstream-to in the future.\n\nMaybe the final note could be removed? Someone who is looking up\n--set-upstream because Git just \"crashed\" on them will only want to know\nwhat they should do instead. Our thoughts about the future are perhaps\nnot that interesting. (I sort of wonder if this option needs to be\ndocumented at all, especially if this doesn't say anything more than\nthe die() just did.)\n\nAlso, I'm wondering if it should be \"has been removed\" instead of \"will\nbe removed\"? /Implementation-wise/, it has not been removed yet, but to\nthe user, it has. So maybe just \"This option has been removed. Consider\nusing --track or --set-upstream-to instead.\" The same below.\n\nI don't know if it's worth trying to use PARSE_OPT_HIDDEN in the\noptions-struct?\n\nMartin\n\n> -u ::\n> --set-upstream-to=::\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index a3bd2262b..2fcb6f7e5 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -755,8 +755,6 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n> strbuf_release(&buf);\n> } else if (argc > 0 && argc <= 2) {\n> struct branch *branch = branch_get(argv[0]);\n> - int branch_existed = 0, remote_tracking = 0;\n> - struct strbuf buf = STRBUF_INIT;\n>\n> if (!strcmp(argv[0], \"HEAD\"))\n> die(_(\"it does not make sense to create 'HEAD' manually\"));\n> @@ -768,28 +766,11 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n> die(_(\"-a and -r options to 'git branch' do not make sense with a branch name\"));\n>\n> if (track == BRANCH_TRACK_OVERRIDE)\n> - fprintf(stderr, _(\"The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\\n\"));\n> + die(_(\"the '--set-upstream' flag is no longer supported and will be removed. Consider using '--track' or '--set-upstream-to'\"));\n>\n> - strbuf_addf(&buf, \"refs/remotes/%s\", branch->name);\n> - remote_tracking = ref_exists(buf.buf);\n> - strbuf_release(&buf);\n> -\n> - branch_existed = ref_exists(branch->refname);\n> create_branch(argv[0], (argc == 2) ? argv[1] : head,\n> force, reflog, 0, quiet, track);\n>\n> - /*\n> - * We only show the instructions if the user gave us\n> - * one branch which doesn't exist locally, but is the\n> - * name of a remote-tracking branch.\n> - */\n> - if (argc == 1 && track == BRANCH_TRACK_OVERRIDE &&\n> - !branch_existed && remote_tracking) {\n> - fprintf(stderr, _(\"\\nIf you wanted to make '%s' track '%s', do this:\\n\\n\"), head, branch->name);\n> - fprintf(stderr, \" git branch -d %s\\n\", branch->name);\n> - fprintf(stderr, \" git branch --set-upstream-to %s\\n\", branch->name);\n> - }\n> -\n> } else\n> usage_with_options(builtin_branch_usage, options);\n"},{"id":"325829","messageId":"CAGZ79ka779gwmLKuSumRdFj3PqXkUe8SfG2ri+qmf_9Z3gsckg@mail.gmail.com","threadId":"46452","inReplyTo":"20170808171136.31168-2-kaarticsivaraam91196@gmail.com","subject":"Re: [PATCH v2 2/2 / RFC] branch: quote branch/ref names to improve readability","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-08T18:55:43Z","receivedAt":"2017-08-08T18:55:50Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 8, 2017 at 10:11 AM, Kaartic Sivaraam\n wrote:\n> Signed-off-by: Kaartic Sivaraam \n> ---\n> branch.c | 16 ++++++++--------\n> 1 file changed, 8 insertions(+), 8 deletions(-)\n\nI like this patch.\n\nIn submodule.c we quote a lot of things (branches, submodules, paths), so\nthis is another step to make the output as a whole more consistent.\n(Though wondering for non-submodule users, if they perceive it as\ninconsistency as other parts of the code may not follow the rigorous quoting)\n\n>\n> diff --git a/branch.c b/branch.c\n> index ad5a2299b..a40721f3c 100644\n> --- a/branch.c\n> +++ b/branch.c\n> @@ -90,24 +90,24 @@ int install_branch_config(int flag, const char *local, const char *origin, const\n> if (shortname) {\n> if (origin)\n> printf_ln(rebasing ?\n> - _(\"Branch %s set up to track remote branch %s from %s by rebasing.\") :\n> - _(\"Branch %s set up to track remote branch %s from %s.\"),\n> + _(\"Branch '%s' set up to track remote branch '%s' from '%s' by rebasing.\") :\n> + _(\"Branch '%s' set up to track remote branch '%s' from '%s'.\"),\n> local, shortname, origin);\n> else\n> printf_ln(rebasing ?\n> - _(\"Branch %s set up to track local branch %s by rebasing.\") :\n> - _(\"Branch %s set up to track local branch %s.\"),\n> + _(\"Branch '%s' set up to track local branch '%s' by rebasing.\") :\n> + _(\"Branch '%s' set up to track local branch '%s'.\"),\n> local, shortname);\n> } else {\n> if (origin)\n> printf_ln(rebasing ?\n> - _(\"Branch %s set up to track remote ref %s by rebasing.\") :\n> - _(\"Branch %s set up to track remote ref %s.\"),\n> + _(\"Branch '%s' set up to track remote ref '%s' by rebasing.\") :\n> + _(\"Branch '%s' set up to track remote ref '%s'.\"),\n> local, remote);\n> else\n> printf_ln(rebasing ?\n> - _(\"Branch %s set up to track local ref %s by rebasing.\") :\n> - _(\"Branch %s set up to track local ref %s.\"),\n> + _(\"Branch '%s' set up to track local ref '%s' by rebasing.\") :\n> + _(\"Branch '%s' set up to track local ref '%s'.\"),\n> local, remote);\n> }\n> }\n> --\n> 2.14.0.rc1.434.g6eded367a\n>\n"},{"id":"325848","messageId":"xmqqh8xhc0c0.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"CAGZ79ka779gwmLKuSumRdFj3PqXkUe8SfG2ri+qmf_9Z3gsckg@mail.gmail.com","subject":"Re: [PATCH v2 2/2 / RFC] branch: quote branch/ref names to improve readability","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-08T19:43:11Z","receivedAt":"2017-08-08T19:43:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> (Though wondering for non-submodule users, if they perceive it as\n> inconsistency as other parts of the code may not follow the rigorous quoting)\n\nDo you mean that we may instead want to remove the excessive quoting\nof branch names and stuff from submodule.c code, because they are\nnewer ones that broke the consistency existed before them (i.e. not\nquoting)?\n\nThat certainly is tempting, but I personally find it easier to read\na message that marks parts that holds \"external data\" differently\nfrom the message's text, so I think this patch 2/2 goes in the right\ndirection.\n"},{"id":"325851","messageId":"CAGZ79kbn4Ew1g4oUhukOF9Qny6OW2wGBRv9QQr3M4E_sWD0ZMg@mail.gmail.com","threadId":"46452","inReplyTo":"xmqqh8xhc0c0.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2 2/2 / RFC] branch: quote branch/ref names to improve readability","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-08T20:08:15Z","receivedAt":"2017-08-08T20:08:21Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 8, 2017 at 12:43 PM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>> (Though wondering for non-submodule users, if they perceive it as\n>> inconsistency as other parts of the code may not follow the rigorous quoting)\n>\n> Do you mean that we may instead want to remove the excessive quoting\n> of branch names and stuff from submodule.c code, because they are\n> newer ones that broke the consistency existed before them (i.e. not\n> quoting)?\n\nNo, I do not. I was just wondering if a non-submodule user\nmay see differences between different commands now.\n\nFor example \"checkout -b\" already quotes 'external data', which\nwould be inline with this proposal, but there may be others.\nMy question was rather an encouragement to check the code base\nif there are other occurrences left that do not quote.\n\nIn an ideal code base we could just grep for any %s that has no\nsurrounding quotes, but of course it is not as easy in the real world:\n* some outputs use %s construction for non-human consumption\n in e.g. the diff machinery\n* sometimes we play sentence lego, stringing words together\n which also is using %s unquoted correctly.\n\n> That certainly is tempting, but I personally find it easier to read\n> a message that marks parts that holds \"external data\" differently\n> from the message's text, so I think this patch 2/2 goes in the right\n> direction.\n\nYes. I like the direction this patch is going.\n\nA note on 'external data':\nFor branchs, paths, submodule names a single quote seems\nto be best (my opinion), whereas in e.g. git-status:\n\n Submodule 'sm1' 0000000...1beffeb (new submodule)\n\nparens seem to do a better job as they describe the state,\nnot reproducing external data. (This is also the place\nwhere I was reminded of potential sentence lego)\n"},{"id":"326265","messageId":"d6faa480-e898-0808-d276-ea516031f454@gmail.com","threadId":"46452","inReplyTo":"CAN0heSqbAdYy-2c0CfO2OxijtvncGWe432bFmkpHZugKDrx-pw@mail.gmail.com","subject":"Re: [PATCH v2 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-14T08:50:05Z","receivedAt":"2017-08-14T08:49:22Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wednesday 09 August 2017 12:03 AM, Martin Ågren wrote:\n> (Also, is this really a refactoring?) \n\nNot quite.\n\n>> --set-upstream::\n>> - If specified branch does not exist yet or if `--force` has been\n>> - given, acts exactly like `--track`. Otherwise sets up configuration\n>> - like `--track` would when creating the branch, except that where\n>> - branch points to is not changed.\n>> + This option is no longer supported and will be removed in the future.\n>> + Consider using --track or --set-upstream-to instead.\n>> ++\n>> +Note: This could possibly become an alias of --set-upstream-to in the future.\n> Maybe the final note could be removed? Someone who is looking up\n> --set-upstream because Git just \"crashed\" on them will only want to know\n> what they should do instead. Our thoughts about the future are perhaps\n> not that interesting.\nI thought it's better to document it to avoid people from getting surprised\nwhen the options *starts working* again.\n\n> (I sort of wonder if this option needs to be\n> documented at all, especially if this doesn't say anything more than\n> the die() just did.)\nYeah, it needs improvement.\n\n> Also, I'm wondering if it should be \"has been removed\" instead of \"will\n> be removed\"? /Implementation-wise/, it has not been removed yet, but to\n> the user, it has. So maybe just \"This option has been removed. Consider\n> using --track or --set-upstream-to instead.\" The same below.\nI guess you're right. I thought \"no longer supported\" was equally\ncommunicative.\n\n"},{"id":"326266","messageId":"20170814085442.31174-1-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170808171136.31168-1-kaarticsivaraam91196@gmail.com","subject":"[PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-14T08:54:42Z","receivedAt":"2017-08-14T08:54:06Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The '--set-upstream' option of branch was deprecated in,\n\n b347d06bf branch: deprecate --set-upstream and show help if we\n detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)\n\nIt was deprecated for the reasons specified in the commit message of the\nreferenced commit.\n\nMake 'branch' die with an appropraite error message when the '--set-upstream'\noption is used.\n\nNote that there's a reason behind \"dying with an error message\" instead of\n\"not accepting the option\". 'git branch' would *accept* '--set-upstream'\neven after it's removal as a consequence of,\n\n Unique prefix can be abbrievated in option names\n\n AND\n\n '--set-upstream' is a unique prefix of '--set-upstream-to'\n (when the '--set-upstream' option has been removed)\n\nIn order to smooth the transition for users and to avoid them being affected\nby the \"prefix issue\" it was decided to make branch die when seeing the\n'--set-upstream' flag for a few years and let the users know that it would be\nremoved some time in the future.\n\nThe before/after behaviour for a simple case follows,\n\n $ git remote\n origin\n\nBefore,\n\n $ git branch\n * master\n\n $ git branch --set-upstream origin/master\n The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\n Branch origin/master set up to track local branch master.\n\n $ echo $?\n 0\n\n $ git branch\n * master\n origin/master\n\nAfter,\n\n $ git branch\n * master\n\n $ git branch --set-upstream origin/master\n fatal: the '--set-upstream' flag is no longer supported and will be removed. Consider using '--track' or '--set-upstream-to'\n\n $ echo $?\n 128\n\n $ git branch\n * master\n\nSigned-off-by: Kaartic Sivaraam \n---\n Changes in v3:\n \n A few tweaks to the following:\n * Commit message\n * Error message (the one shown when '--set-upstream' is seen)\n * Updated the corresponding message in the options structure\n * Documentation\n\n A query,\n\n I see the following code in the code path a little above the die statement\n added in this change,\n\n if (!strcmp(argv[0], \"HEAD\"))\n \t\t \tdie(_(\"it does not make sense to create 'HEAD' manually\"));\n\n It does seem to be doing quite a nice job of avoiding an ambiguity that could\n have bad consequences but it's still possible to create a branch named 'HEAD'\n using the '-b' option of 'checkout'. Should 'git checkout -b HEAD' actually\n fail(it does not currently) for the same reason 'git branch HEAD' fails?\n\n My guess is that people would use 'git checkout -b '\n more than it's 'git branch' counterpart. \n\n\n Documentation/git-branch.txt | 8 +++----\n builtin/branch.c | 23 ++------------------\n t/t3200-branch.sh | 50 ++++----------------------------------------\n t/t6040-tracking-info.sh | 16 +++++++-------\n 4 files changed, 18 insertions(+), 79 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 81bd0a7b7..93ee05c55 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -195,10 +195,10 @@ start-point is either a local or remote-tracking branch.\n \tbranch.autoSetupMerge configuration variable is true.\n \n --set-upstream::\n-\tIf specified branch does not exist yet or if `--force` has been\n-\tgiven, acts exactly like `--track`. Otherwise sets up configuration\n-\tlike `--track` would when creating the branch, except that where\n-\tbranch points to is not changed.\n+\tAs this option has confusing syntax it's no longer supported. Please use\n+ --track or --set-upstream-to instead.\n++\n+Note: This could possibly become an alias of --set-upstream-to in the future.\n \n -u ::\n --set-upstream-to=::\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex a3bd2262b..b92070393 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -557,7 +557,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tOPT__QUIET(&quiet, N_(\"suppress informational messages\")),\n \t\tOPT_SET_INT('t', \"track\", &track, N_(\"set up tracking mode (see git-pull(1))\"),\n \t\t\tBRANCH_TRACK_EXPLICIT),\n-\t\tOPT_SET_INT( 0, \"set-upstream\", &track, N_(\"change upstream info\"),\n+\t\tOPT_SET_INT( 0, \"set-upstream\", &track, N_(\"no longer supported\"),\n \t\t\tBRANCH_TRACK_OVERRIDE),\n \t\tOPT_STRING('u', \"set-upstream-to\", &new_upstream, N_(\"upstream\"), N_(\"change the upstream info\")),\n \t\tOPT_BOOL(0, \"unset-upstream\", &unset_upstream, N_(\"Unset the upstream info\")),\n@@ -755,8 +755,6 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tstrbuf_release(&buf);\n \t} else if (argc > 0 && argc <= 2) {\n \t\tstruct branch *branch = branch_get(argv[0]);\n-\t\tint branch_existed = 0, remote_tracking = 0;\n-\t\tstruct strbuf buf = STRBUF_INIT;\n \n \t\tif (!strcmp(argv[0], \"HEAD\"))\n \t\t\tdie(_(\"it does not make sense to create 'HEAD' manually\"));\n@@ -768,28 +766,11 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tdie(_(\"-a and -r options to 'git branch' do not make sense with a branch name\"));\n \n \t\tif (track == BRANCH_TRACK_OVERRIDE)\n-\t\t\tfprintf(stderr, _(\"The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\\n\"));\n+\t\t\tdie(_(\"the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.\"));\n \n-\t\tstrbuf_addf(&buf, \"refs/remotes/%s\", branch->name);\n-\t\tremote_tracking = ref_exists(buf.buf);\n-\t\tstrbuf_release(&buf);\n-\n-\t\tbranch_existed = ref_exists(branch->refname);\n \t\tcreate_branch(argv[0], (argc == 2) ? argv[1] : head,\n \t\t\t force, reflog, 0, quiet, track);\n \n-\t\t/*\n-\t\t * We only show the instructions if the user gave us\n-\t\t * one branch which doesn't exist locally, but is the\n-\t\t * name of a remote-tracking branch.\n-\t\t */\n-\t\tif (argc == 1 && track == BRANCH_TRACK_OVERRIDE &&\n-\t\t !branch_existed && remote_tracking) {\n-\t\t\tfprintf(stderr, _(\"\\nIf you wanted to make '%s' track '%s', do this:\\n\\n\"), head, branch->name);\n-\t\t\tfprintf(stderr, \" git branch -d %s\\n\", branch->name);\n-\t\t\tfprintf(stderr, \" git branch --set-upstream-to %s\\n\", branch->name);\n-\t\t}\n-\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 dd37ac47c..249be4b1a 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -561,7 +561,8 @@ test_expect_success 'use --set-upstream-to modify a particular branch' '\n \tgit branch my13 &&\n \tgit branch --set-upstream-to master my13 &&\n \ttest \"$(git config branch.my13.remote)\" = \".\" &&\n-\ttest \"$(git config branch.my13.merge)\" = \"refs/heads/master\"\n+\ttest \"$(git config branch.my13.merge)\" = \"refs/heads/master\" &&\n+\tgit branch --unset-upstream my13\n '\n \n test_expect_success '--unset-upstream should fail if given a non-existent branch' '\n@@ -605,38 +606,8 @@ test_expect_success 'test --unset-upstream on a particular branch' '\n \ttest_must_fail git config branch.my14.merge\n '\n \n-test_expect_success '--set-upstream shows message when creating a new branch that exists as remote-tracking' '\n-\tgit update-ref refs/remotes/origin/master HEAD &&\n-\tgit branch --set-upstream origin/master 2>actual &&\n-\ttest_when_finished git update-ref -d refs/remotes/origin/master &&\n-\ttest_when_finished git branch -d origin/master &&\n-\tcat >expected <actual &&\n-\ttest_when_finished git branch --unset-upstream master &&\n-\tcat >expected <actual &&\n-\ttest_when_finished git branch --unset-upstream my13 &&\n-\tcat >expected <\"$1\"\ndiff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh\nindex 97a07655a..4b522f456 100755\n--- a/t/t6040-tracking-info.sh\n+++ b/t/t6040-tracking-info.sh\n@@ -188,35 +188,35 @@ test_expect_success 'fail to track annotated tags' '\n \ttest_must_fail git checkout heavytrack\n '\n \n-test_expect_success 'setup tracking with branch --set-upstream on existing branch' '\n+test_expect_success 'setup tracking with branch --set-upstream-to on existing branch' '\n \tgit branch from-master master &&\n \ttest_must_fail git config branch.from-master.merge > actual &&\n-\tgit branch --set-upstream from-master master &&\n+\tgit branch --set-upstream-to master from-master &&\n \tgit config branch.from-master.merge > actual &&\n \tgrep -q \"^refs/heads/master$\" actual\n '\n \n-test_expect_success '--set-upstream does not change branch' '\n+test_expect_success '--set-upstream-to does not change branch' '\n \tgit branch from-master2 master &&\n \ttest_must_fail git config branch.from-master2.merge > actual &&\n \tgit rev-list from-master2 &&\n \tgit update-ref refs/heads/from-master2 from-master2^ &&\n \tgit rev-parse from-master2 >expect2 &&\n-\tgit branch --set-upstream from-master2 master &&\n+\tgit branch --set-upstream-to master from-master2 &&\n \tgit config branch.from-master.merge > actual &&\n \tgit rev-parse from-master2 >actual2 &&\n \tgrep -q \"^refs/heads/master$\" actual &&\n \tcmp expect2 actual2\n '\n \n-test_expect_success '--set-upstream @{-1}' '\n-\tgit checkout from-master &&\n+test_expect_success '--set-upstream-to @{-1}' '\n+\tgit checkout follower &&\n \tgit checkout from-master2 &&\n \tgit config branch.from-master2.merge > expect2 &&\n-\tgit branch --set-upstream @{-1} follower &&\n+\tgit branch --set-upstream-to @{-1} from-master &&\n \tgit config branch.from-master.merge > actual &&\n \tgit config branch.from-master2.merge > actual2 &&\n-\tgit branch --set-upstream from-master follower &&\n+\tgit branch --set-upstream-to follower from-master &&\n \tgit config branch.from-master.merge > expect &&\n \ttest_cmp expect2 actual2 &&\n \ttest_cmp expect actual\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"326297","messageId":"CAN0heSr1FjayzX-SnNVcgQuh+Cc-f=AjY8H=pGG6uvf8rrJM=A@mail.gmail.com","threadId":"46452","inReplyTo":"20170814085442.31174-1-kaarticsivaraam91196@gmail.com","subject":"Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Martin Ågren","fromEmail":"martin.agren@gmail.com","sentAt":"2017-08-14T19:14:19Z","receivedAt":"2017-08-14T19:14:35Z","isPatch":true,"sender":{"key":"martin.agren@gmail.com","avatar":null},"body":"On 14 August 2017 at 10:54, Kaartic Sivaraam\n wrote:\n> The '--set-upstream' option of branch was deprecated in,\n>\n> b347d06bf branch: deprecate --set-upstream and show help if we\n> detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)\n>\n> It was deprecated for the reasons specified in the commit message of the\n> referenced commit.\n>\n> Make 'branch' die with an appropraite error message when the '--set-upstream'\n> option is used.\n>\n> Note that there's a reason behind \"dying with an error message\" instead of\n> \"not accepting the option\". 'git branch' would *accept* '--set-upstream'\n> even after it's removal as a consequence of,\n>\n> Unique prefix can be abbrievated in option names\n>\n> AND\n>\n> '--set-upstream' is a unique prefix of '--set-upstream-to'\n> (when the '--set-upstream' option has been removed)\n>\n> In order to smooth the transition for users and to avoid them being affected\n> by the \"prefix issue\" it was decided to make branch die when seeing the\n> '--set-upstream' flag for a few years and let the users know that it would be\n> removed some time in the future.\n>\n> The before/after behaviour for a simple case follows,\n>\n> $ git remote\n> origin\n>\n> Before,\n>\n> $ git branch\n> * master\n>\n> $ git branch --set-upstream origin/master\n> The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\n> Branch origin/master set up to track local branch master.\n>\n> $ echo $?\n> 0\n>\n> $ git branch\n> * master\n> origin/master\n>\n> After,\n>\n> $ git branch\n> * master\n>\n> $ git branch --set-upstream origin/master\n> fatal: the '--set-upstream' flag is no longer supported and will be removed. Consider using '--track' or '--set-upstream-to'\n>\n> $ echo $?\n> 128\n>\n> $ git branch\n> * master\n>\n> Signed-off-by: Kaartic Sivaraam \n> ---\n> Changes in v3:\n>\n> A few tweaks to the following:\n> * Commit message\n> * Error message (the one shown when '--set-upstream' is seen)\n> * Updated the corresponding message in the options structure\n> * Documentation\n>\n> A query,\n>\n> I see the following code in the code path a little above the die statement\n> added in this change,\n>\n> if (!strcmp(argv[0], \"HEAD\"))\n> die(_(\"it does not make sense to create 'HEAD' manually\"));\n>\n> It does seem to be doing quite a nice job of avoiding an ambiguity that could\n> have bad consequences but it's still possible to create a branch named 'HEAD'\n> using the '-b' option of 'checkout'. Should 'git checkout -b HEAD' actually\n> fail(it does not currently) for the same reason 'git branch HEAD' fails?\n>\n> My guess is that people would use 'git checkout -b '\n> more than it's 'git branch' counterpart.\n>\n>\n> Documentation/git-branch.txt | 8 +++----\n> builtin/branch.c | 23 ++------------------\n> t/t3200-branch.sh | 50 ++++----------------------------------------\n> t/t6040-tracking-info.sh | 16 +++++++-------\n> 4 files changed, 18 insertions(+), 79 deletions(-)\n>\n> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\n> index 81bd0a7b7..93ee05c55 100644\n> --- a/Documentation/git-branch.txt\n> +++ b/Documentation/git-branch.txt\n> @@ -195,10 +195,10 @@ start-point is either a local or remote-tracking branch.\n> branch.autoSetupMerge configuration variable is true.\n>\n> --set-upstream::\n> - If specified branch does not exist yet or if `--force` has been\n> - given, acts exactly like `--track`. Otherwise sets up configuration\n> - like `--track` would when creating the branch, except that where\n> - branch points to is not changed.\n> + As this option has confusing syntax it's no longer supported. Please use\n\n\"has\" or \"had\"? (I guess when someone reads this, it \"has\" no syntax at\nall. ;) )\n\n> + --track or --set-upstream-to instead.\n\nMaybe indent with a tab instead of two spaces for consistency with the\nrest of the file.\n\n> ++\n> +Note: This could possibly become an alias of --set-upstream-to in the future.\n\n(But not here.)\n\n>\n> -u ::\n> --set-upstream-to=::\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index a3bd2262b..b92070393 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -557,7 +557,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n> OPT__QUIET(&quiet, N_(\"suppress informational messages\")),\n> OPT_SET_INT('t', \"track\", &track, N_(\"set up tracking mode (see git-pull(1))\"),\n> BRANCH_TRACK_EXPLICIT),\n> - OPT_SET_INT( 0, \"set-upstream\", &track, N_(\"change upstream info\"),\n> + OPT_SET_INT( 0, \"set-upstream\", &track, N_(\"no longer supported\"),\n> BRANCH_TRACK_OVERRIDE),\n> OPT_STRING('u', \"set-upstream-to\", &new_upstream, N_(\"upstream\"), N_(\"change the upstream info\")),\n> OPT_BOOL(0, \"unset-upstream\", &unset_upstream, N_(\"Unset the upstream info\")),\n> @@ -755,8 +755,6 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n> strbuf_release(&buf);\n> } else if (argc > 0 && argc <= 2) {\n> struct branch *branch = branch_get(argv[0]);\n> - int branch_existed = 0, remote_tracking = 0;\n> - struct strbuf buf = STRBUF_INIT;\n>\n> if (!strcmp(argv[0], \"HEAD\"))\n> die(_(\"it does not make sense to create 'HEAD' manually\"));\n> @@ -768,28 +766,11 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n> die(_(\"-a and -r options to 'git branch' do not make sense with a branch name\"));\n>\n> if (track == BRANCH_TRACK_OVERRIDE)\n> - fprintf(stderr, _(\"The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\\n\"));\n> + die(_(\"the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.\"));\n>\n> - strbuf_addf(&buf, \"refs/remotes/%s\", branch->name);\n> - remote_tracking = ref_exists(buf.buf);\n> - strbuf_release(&buf);\n> -\n> - branch_existed = ref_exists(branch->refname);\n> create_branch(argv[0], (argc == 2) ? argv[1] : head,\n> force, reflog, 0, quiet, track);\n>\n> - /*\n> - * We only show the instructions if the user gave us\n> - * one branch which doesn't exist locally, but is the\n> - * name of a remote-tracking branch.\n> - */\n> - if (argc == 1 && track == BRANCH_TRACK_OVERRIDE &&\n> - !branch_existed && remote_tracking) {\n> - fprintf(stderr, _(\"\\nIf you wanted to make '%s' track '%s', do this:\\n\\n\"), head, branch->name);\n> - fprintf(stderr, \" git branch -d %s\\n\", branch->name);\n> - fprintf(stderr, \" git branch --set-upstream-to %s\\n\", branch->name);\n> - }\n> -\n\nNice. :)\n\n> } else\n> usage_with_options(builtin_branch_usage, options);\n>\n> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\n> index dd37ac47c..249be4b1a 100755\n> --- a/t/t3200-branch.sh\n> +++ b/t/t3200-branch.sh\n> @@ -561,7 +561,8 @@ test_expect_success 'use --set-upstream-to modify a particular branch' '\n> git branch my13 &&\n> git branch --set-upstream-to master my13 &&\n> test \"$(git config branch.my13.remote)\" = \".\" &&\n> - test \"$(git config branch.my13.merge)\" = \"refs/heads/master\"\n> + test \"$(git config branch.my13.merge)\" = \"refs/heads/master\" &&\n> + git branch --unset-upstream my13\n\nI think it would be safer to use test_when_finished like on line 625.\nOut of curiosity: are you adding this out of caution, or did some later\ntest fail without this?\n\n> '\n>\n> test_expect_success '--unset-upstream should fail if given a non-existent branch' '\n> @@ -605,38 +606,8 @@ test_expect_success 'test --unset-upstream on a particular branch' '\n> test_must_fail git config branch.my14.merge\n> '\n>\n> -test_expect_success '--set-upstream shows message when creating a new branch that exists as remote-tracking' '\n> - git update-ref refs/remotes/origin/master HEAD &&\n> - git branch --set-upstream origin/master 2>actual &&\n> - test_when_finished git update-ref -d refs/remotes/origin/master &&\n> - test_when_finished git branch -d origin/master &&\n> - cat >expected < -The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\n> -\n> -If you wanted to make '\"'master'\"' track '\"'origin/master'\"', do this:\n> -\n> - git branch -d origin/master\n> - git branch --set-upstream-to origin/master\n> -EOF\n> - test_i18ncmp expected actual\n> -'\n> -\n> -test_expect_success '--set-upstream with two args only shows the deprecation message' '\n> - git branch --set-upstream master my13 2>actual &&\n> - test_when_finished git branch --unset-upstream master &&\n> - cat >expected < -The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\n> -EOF\n> - test_i18ncmp expected actual\n> -'\n> -\n> -test_expect_success '--set-upstream with one arg only shows the deprecation message if the branch existed' '\n> - git branch --set-upstream my13 2>actual &&\n> - test_when_finished git branch --unset-upstream my13 &&\n> - cat >expected < -The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\n> -EOF\n> - test_i18ncmp expected actual\n> +test_expect_success '--set-upstream fails' '\n> + test_must_fail git branch --set-upstream origin/master\n> '\n>\n> test_expect_success '--set-upstream-to notices an error to set branch as own upstream' '\n> @@ -961,19 +932,6 @@ test_expect_success 'attempt to delete a branch merged to its base' '\n> test_must_fail git branch -d my10\n> '\n>\n> -test_expect_success 'use set-upstream on the current branch' '\n> - git checkout master &&\n> - git --bare init myupstream.git &&\n> - git push myupstream.git master:refs/heads/frotz &&\n> - git remote add origin myupstream.git &&\n> - git fetch &&\n> - git branch --set-upstream master origin/frotz &&\n> -\n> - test \"z$(git config branch.master.remote)\" = \"zorigin\" &&\n> - test \"z$(git config branch.master.merge)\" = \"zrefs/heads/frotz\"\n> -\n> -'\n> -\n> test_expect_success 'use --edit-description' '\n> write_script editor <<-\\EOF &&\n> echo \"New contents\" >\"$1\"\n> diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh\n> index 97a07655a..4b522f456 100755\n> --- a/t/t6040-tracking-info.sh\n> +++ b/t/t6040-tracking-info.sh\n> @@ -188,35 +188,35 @@ test_expect_success 'fail to track annotated tags' '\n> test_must_fail git checkout heavytrack\n> '\n>\n> -test_expect_success 'setup tracking with branch --set-upstream on existing branch' '\n> +test_expect_success 'setup tracking with branch --set-upstream-to on existing branch' '\n> git branch from-master master &&\n> test_must_fail git config branch.from-master.merge > actual &&\n> - git branch --set-upstream from-master master &&\n> + git branch --set-upstream-to master from-master &&\n> git config branch.from-master.merge > actual &&\n> grep -q \"^refs/heads/master$\" actual\n> '\n>\n> -test_expect_success '--set-upstream does not change branch' '\n> +test_expect_success '--set-upstream-to does not change branch' '\n> git branch from-master2 master &&\n> test_must_fail git config branch.from-master2.merge > actual &&\n> git rev-list from-master2 &&\n> git update-ref refs/heads/from-master2 from-master2^ &&\n> git rev-parse from-master2 >expect2 &&\n> - git branch --set-upstream from-master2 master &&\n> + git branch --set-upstream-to master from-master2 &&\n> git config branch.from-master.merge > actual &&\n> git rev-parse from-master2 >actual2 &&\n> grep -q \"^refs/heads/master$\" actual &&\n> cmp expect2 actual2\n> '\n\nThe two tests above were added when --set-upstream was originally added.\nNow that you're converting them to use --set-upstream-to, to what extent\ndo they just test the same thing as the tests in t3200?\n\n>\n> -test_expect_success '--set-upstream @{-1}' '\n> - git checkout from-master &&\n> +test_expect_success '--set-upstream-to @{-1}' '\n> + git checkout follower &&\n> git checkout from-master2 &&\n> git config branch.from-master2.merge > expect2 &&\n> - git branch --set-upstream @{-1} follower &&\n> + git branch --set-upstream-to @{-1} from-master &&\n> git config branch.from-master.merge > actual &&\n> git config branch.from-master2.merge > actual2 &&\n> - git branch --set-upstream from-master follower &&\n> + git branch --set-upstream-to follower from-master &&\n> git config branch.from-master.merge > expect &&\n> test_cmp expect2 actual2 &&\n> test_cmp expect actual\n\nI couldn't find any test of --set-upstream-to=@{...} in t3200, so this\nprobably does test something previously untested.\n\nMartin\n"},{"id":"326305","messageId":"xmqqy3qluck4.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"20170814085442.31174-1-kaarticsivaraam91196@gmail.com","subject":"Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-14T20:19:55Z","receivedAt":"2017-08-14T20:20:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> The '--set-upstream' option of branch was deprecated in,\n>\n> b347d06bf branch: deprecate --set-upstream and show help if we\n> detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)\n>\n> It was deprecated for the reasons specified in the commit message of the\n> referenced commit.\n\nI wonder if these two lines add any value here. Those who know the\nreason would not be helped, and those who don't know have to view\n\"git show b347d06bf\" anyway.\n\n> Make 'branch' die with an appropraite error message when the '--set-upstream'\n> option is used.\n\nOK.\n\n> Note that there's a reason behind \"dying with an error message\" instead of\n> \"not accepting the option\". 'git branch' would *accept* '--set-upstream'\n> even after it's removal as a consequence of,\n>\n> Unique prefix can be abbrievated in option names\n>\n> AND\n>\n> '--set-upstream' is a unique prefix of '--set-upstream-to'\n> (when the '--set-upstream' option has been removed)\n>\n> In order to smooth the transition for users and to avoid them being affected\n> by the \"prefix issue\" it was decided to make branch die when seeing the\n> '--set-upstream' flag for a few years and let the users know that it would be\n> removed some time in the future.\n\nI somehow think the above wastes bits a bit too much. Wouldn't it\nbe sufficient to say\n\n In order to prevent \"--set-upstream\" on a command line from\n being taken as an abbreviated form of \"--set-upstream-to\",\n explicitly catch \"--set-upstream\" option and die, instead of\n just removing it from the list of options.\n\n> $ git branch --set-upstream origin/master\n> The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\n> Branch origin/master set up to track local branch master.\n\n> After,\n>\n> $ git branch\n> * master\n>\n> $ git branch --set-upstream origin/master\n> fatal: the '--set-upstream' flag is no longer supported and will be removed. Consider using '--track' or '--set-upstream-to'\n\nBecause from the end-user's point of view, it has already been\nremoved, I'd phrase it more like\n\n\tThe --set-upstream option has been removed. Use --track or ...\n\nand make sure we do not list \"--set-upstream\" in the list of\nsupported options in\n\n\tgit branch -h\n\noutput.\n\n> A query,\n>\n> I see the following code in the code path a little above the die statement\n> added in this change,\n>\n> if (!strcmp(argv[0], \"HEAD\"))\n> \t\t \tdie(_(\"it does not make sense to create 'HEAD' manually\"));\n>\n> It does seem to be doing quite a nice job of avoiding an ambiguity that could\n> have bad consequences but it's still possible to create a branch named 'HEAD'\n> using the '-b' option of 'checkout'. Should 'git checkout -b HEAD' actually\n> fail(it does not currently) for the same reason 'git branch HEAD' fails?\n>\n> My guess is that people would use 'git checkout -b '\n> more than it's 'git branch' counterpart. \n\nThanks for noticing. I offhand see no reason not to do what you\nsuggest above.\n\n> -\t\tOPT_SET_INT( 0, \"set-upstream\", &track, N_(\"change upstream info\"),\n> +\t\tOPT_SET_INT( 0, \"set-upstream\", &track, N_(\"no longer supported\"),\n> \t\t\tBRANCH_TRACK_OVERRIDE),\n\nHere we would want to use something like\n\n\t{ OPTION_SET_INT, 0, \"set-upstream\", &track, NULL, N_(\"do not use\"),\n\t PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, BRANCH_TRACK_OVERRIDE },\n\nin order to hide the option from \"git branch -h\" output.\n\nAll review comments from Martin were also good ones, and I won't\nrepeat them here.\n\nThanks.\n\n\n"},{"id":"326371","messageId":"b12f73f0-b4de-e96e-f102-2ec919ca8db5@gmail.com","threadId":"46452","inReplyTo":"CAN0heSr1FjayzX-SnNVcgQuh+Cc-f=AjY8H=pGG6uvf8rrJM=A@mail.gmail.com","subject":"Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-15T10:23:57Z","receivedAt":"2017-08-15T10:23:16Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Tuesday 15 August 2017 12:44 AM, Martin Ågren wrote:\n>> --set-upstream::\n>> - If specified branch does not exist yet or if `--force` has been\n>> - given, acts exactly like `--track`. Otherwise sets up configuration\n>> - like `--track` would when creating the branch, except that where\n>> - branch points to is not changed.\n>> + As this option has confusing syntax it's no longer supported. Please use\n> \"has\" or \"had\"? (I guess when someone reads this, it \"has\" no syntax at\n> all. ;) )\nGot it.\n>> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\n>> index dd37ac47c..249be4b1a 100755\n>> --- a/t/t3200-branch.sh\n>> +++ b/t/t3200-branch.sh\n>> @@ -561,7 +561,8 @@ test_expect_success 'use --set-upstream-to modify a particular branch' '\n>> git branch my13 &&\n>> git branch --set-upstream-to master my13 &&\n>> test \"$(git config branch.my13.remote)\" = \".\" &&\n>> - test \"$(git config branch.my13.merge)\" = \"refs/heads/master\"\n>> + test \"$(git config branch.my13.merge)\" = \"refs/heads/master\" &&\n>> + git branch --unset-upstream my13\n> I think it would be safer to use test_when_finished like on line 625.\n> Out of curiosity: are you adding this out of caution, or did some later\n> test fail without this?\nOne test seems to fail without this. I guess it's better to keep this \nchange as a separate\ncommit.\n\n>> diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh\n>> index 97a07655a..4b522f456 100755\n>> --- a/t/t6040-tracking-info.sh\n>> +++ b/t/t6040-tracking-info.sh\n>> @@ -188,35 +188,35 @@ test_expect_success 'fail to track annotated tags' '\n>> test_must_fail git checkout heavytrack\n>> '\n>>\n>> -test_expect_success 'setup tracking with branch --set-upstream on existing branch' '\n>> +test_expect_success 'setup tracking with branch --set-upstream-to on existing branch' '\n>> git branch from-master master &&\n>> test_must_fail git config branch.from-master.merge > actual &&\n>> - git branch --set-upstream from-master master &&\n>> + git branch --set-upstream-to master from-master &&\n>> git config branch.from-master.merge > actual &&\n>> grep -q \"^refs/heads/master$\" actual\n>> '\n>>\n>> -test_expect_success '--set-upstream does not change branch' '\n>> +test_expect_success '--set-upstream-to does not change branch' '\n>> git branch from-master2 master &&\n>> test_must_fail git config branch.from-master2.merge > actual &&\n>> git rev-list from-master2 &&\n>> git update-ref refs/heads/from-master2 from-master2^ &&\n>> git rev-parse from-master2 >expect2 &&\n>> - git branch --set-upstream from-master2 master &&\n>> + git branch --set-upstream-to master from-master2 &&\n>> git config branch.from-master.merge > actual &&\n>> git rev-parse from-master2 >actual2 &&\n>> grep -q \"^refs/heads/master$\" actual &&\n>> cmp expect2 actual2\n>> '\n> The two tests above were added when --set-upstream was originally added.\n> Now that you're converting them to use --set-upstream-to, to what extent\n> do they just test the same thing as the tests in t3200?\nThe first seems useless, I'll remove it. Regarding the second one, as \nfar as I could see\nthere's no test in t3200 that does something similar so I guess it could \nbe kept back.\n\n---\nKaartic\n"},{"id":"326380","messageId":"772aaebf-81ea-ac22-9d2f-35d0778f502f@gmail.com","threadId":"46452","inReplyTo":"xmqqy3qluck4.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-15T10:56:29Z","receivedAt":"2017-08-15T10:55:50Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Tuesday 15 August 2017 01:49 AM, Junio C Hamano wrote:\n> I wonder if these two lines add any value here. Those who know the\n> reason would not be helped, and those who don't know have to view\n> \"git show b347d06bf\" anyway.\nThat's right.\n\n>\n> I somehow think the above wastes bits a bit too much. Wouldn't it\n> be sufficient to say\n>\n> In order to prevent \"--set-upstream\" on a command line from\n> being taken as an abbreviated form of \"--set-upstream-to\",\n> explicitly catch \"--set-upstream\" option and die, instead of\n> just removing it from the list of options.\nThanks for the shorter version. I'll use this :)\n\n> Because from the end-user's point of view, it has already been\n> removed, I'd phrase it more like\n>\n> \tThe --set-upstream option has been removed. Use --track or ...\nI thought I changed it. It seems to have gone missing. Thanks for \nnoticing this.\n\n> and make sure we do not list \"--set-upstream\" in the list of\n> supported options in\n>\n> \tgit branch -h\n>\n> output.\nI guess the instructions given below are enough. They do seem to be \ndoing hiding it\nfrom 'git branch -h'\n\n> Here we would want to use something like\n> \t{ OPTION_SET_INT, 0, \"set-upstream\", &track, NULL, N_(\"do not use\"),\n> \t PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, BRANCH_TRACK_OVERRIDE },\n>\n> in order to hide the option from \"git branch -h\" output.\n>\n> All review comments from Martin were also good ones, and I won't\n> repeat them here.\n>\n\n>> A query,\n>>\n>> I see the following code in the code path a little above the die statement\n>> added in this change,\n>>\n>> if (!strcmp(argv[0], \"HEAD\"))\n>> \t\t \tdie(_(\"it does not make sense to create 'HEAD' manually\"));\n>>\n>> It does seem to be doing quite a nice job of avoiding an ambiguity that could\n>> have bad consequences but it's still possible to create a branch named 'HEAD'\n>> using the '-b' option of 'checkout'. Should 'git checkout -b HEAD' actually\n>> fail(it does not currently) for the same reason 'git branch HEAD' fails?\n>>\n>> My guess is that people would use 'git checkout -b '\n>> more than it's 'git branch' counterpart.\n> Thanks for noticing. I offhand see no reason not to do what you\n> suggest above.\nThere are two ways in which this could be done.\n\n1. Duplicate the check done in 'builtin/branch.c' in \n'builtin/checkout.c'. This doesn't\n sound good to me.\n\n2. Do the check in 'branch.c::validate_new_branchname' to ensure there's \nno way to\n create a branch with the name of 'HEAD'.\n\nWhich one is preferred?\n"},{"id":"326438","messageId":"xmqqfucsr73w.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"772aaebf-81ea-ac22-9d2f-35d0778f502f@gmail.com","subject":"Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-15T18:58:11Z","receivedAt":"2017-08-15T18:58:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> 1. Duplicate the check done in 'builtin/branch.c' in\n> 'builtin/checkout.c'. This doesn't\n> sound good to me.\n\nDoesn't sound good to me, either. Some refactoring to make it\neasier to reuse it from the new caller would be necessary.\n"},{"id":"326519","messageId":"09ce545a-31ff-aa9f-d03c-3cb68ed26230@gmail.com","threadId":"46452","inReplyTo":"xmqqfucsr73w.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-16T18:13:09Z","receivedAt":"2017-08-16T18:12:25Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wednesday 16 August 2017 12:28 AM, Junio C Hamano wrote:\n> Some refactoring to make it easier to reuse it from the new caller \n> would be necessary. \nSorry but I think I don't get that correctly. What's the \"new caller\" \nbeing referred to here?\nWhat should be refactored?\n\n---\nKaartic\n\n"},{"id":"326530","messageId":"xmqq378rl479.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"09ce545a-31ff-aa9f-d03c-3cb68ed26230@gmail.com","subject":"Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-16T19:09:46Z","receivedAt":"2017-08-16T19:09:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> On Wednesday 16 August 2017 12:28 AM, Junio C Hamano wrote:\n>> Some refactoring to make it easier to reuse it from the new caller\n>> would be necessary. \n> Sorry but I think I don't get that correctly. What's the \"new caller\"\n> being referred to here?\n> What should be refactored?\n\nYou said that \"checkout\" does not do a necessary check that is done\nin \"branch\", so presumably \"branch\" already has a code to do so that\nis not called by the current \"checkout\", right? Then you would add\na new caller in \"checkout\" to trigger the same check that is already\ndone in \"branch\", but the code \"branch\" uses _might_ be too specific\nto the kind of data the current implementation of \"branch\" uses and\nit _may_ not be easy to call it directly from \"checkout\" (I didn't\ncheck if that is the case). If so, then the check implemented in\nthe current \"branch\" may need to be refactored before it can easily\nbe called from the new caller you would be adding to \"checkout\".\n\n\n"},{"id":"326571","messageId":"1502935475.1710.5.camel@gmail.com","threadId":"46452","inReplyTo":"xmqq378rl479.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-17T02:04:35Z","receivedAt":"2017-08-17T02:03:56Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wed, 2017-08-16 at 12:09 -0700, Junio C Hamano wrote:\n> You said that \"checkout\" does not do a necessary check that is done\n> in \"branch\", so presumably \"branch\" already has a code to do so that\n> is not called by the current \"checkout\", right? Then you would add\n> a new caller in \"checkout\" to trigger the same check that is already\n> done in \"branch\", but the code \"branch\" uses _might_ be too specific\n> to the kind of data the current implementation of \"branch\" uses and\n> it _may_ not be easy to call it directly from \"checkout\" (I didn't\n> check if that is the case). If so, then the check implemented in\n> the current \"branch\" may need to be refactored before it can easily\n> be called from the new caller you would be adding to \"checkout\".\n> \n> \nThanks. Now I get it. What about doing that check in\nbranch.c::create_branch or branch.c::validate_new_branchname? I guess\ncreating a branch named HEAD isn't that good an idea in any case. Doing\nthe check there might prevent a similar situation in future, I guess.\nFurther \"branch\" and \"checkout\" do call branch.c::create_branch which\nin turn calls branch.c::validate_new_branchname.\n\n-- \nKaartic\n"},{"id":"326574","messageId":"20170817025425.6647-1-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"xmqqy3qluck4.fsf@gitster.mtv.corp.google.com","subject":"[PATCH v4 1/3] test: cleanup cruft of a test","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-17T02:54:23Z","receivedAt":"2017-08-17T02:53:47Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Avoiding the clean up step of tests may help in some cases but in other\ncases they cause the other unrelated tests to fail for unobvious reasons.\nIt's better to cleanup a few things to keep other tests from failing\nas a result of it.\n\nSo, cleanup a cruft left behind by an old test in order for the changes that\nare to be introduced to be independent of it.\n\nSigned-off-by: Kaartic Sivaraam \n---\n This was part of [PATCH v3 1/2] and has been separated as it seemed to be\n a \"logically separate\" change.\n\n t/t3200-branch.sh | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex dd37ac47c..b54b3ebf3 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -560,6 +560,7 @@ test_expect_success 'use --set-upstream-to modify HEAD' '\n test_expect_success 'use --set-upstream-to modify a particular branch' '\n \tgit branch my13 &&\n \tgit branch --set-upstream-to master my13 &&\n+\ttest_when_finished \"git branch --unset-upstream my13\" &&\n \ttest \"$(git config branch.my13.remote)\" = \".\" &&\n \ttest \"$(git config branch.my13.merge)\" = \"refs/heads/master\"\n '\n-- \n2.14.1.534.g641031ecb\n\n"},{"id":"326575","messageId":"20170817025425.6647-2-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170817025425.6647-1-kaarticsivaraam91196@gmail.com","subject":"[PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-17T02:54:24Z","receivedAt":"2017-08-17T02:53:52Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The '--set-upstream' option of branch was deprecated in,\n\n b347d06bf branch: deprecate --set-upstream and show help if we\n detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)\n\nIn order to prevent \"--set-upstream\" on a command line from being taken as\nan abbreviated form of \"--set-upstream-to\", explicitly catch \"--set-upstream\"\noption and die, instead of just removing it from the list of options.\n\nThe option is planned to be removed after this change has been around for a few\nyears.\n\nThe before/after behaviour for a simple case follows,\n\n $ git remote\n origin\n\nBefore,\n\n $ git branch\n * master\n\n $ git branch --set-upstream origin/master\n The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\n Branch origin/master set up to track local branch master.\n\n $ echo $?\n 0\n\n $ git branch\n * master\n origin/master\n\nAfter,\n\n $ git branch\n * master\n\n $ git branch --set-upstream origin/master\n fatal: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.\n\n $ echo $?\n 128\n\n $ git branch\n * master\n\nHelped-by: Martin Ågren , Junio C Hamano \nSigned-off-by: Kaartic Sivaraam \n---\n Changes in v4:\n\n - made a few changes suggested by Martin\n - hid the '--set-upstream' option from 'git branch -h' as suggested by Junio \n - updated commit message as suggested by Junio\n - updated error message (this should have been in v3 but somehow got skipped)\n\n Note: I'm not using the word 'removed' in the error messages or in the documentation as\n I feel it counter-intuitive from the end user's perspective because \n\n * 'git branch' still accepts the option in the command line\n\n * The option has not yet been removed from the synopsis of the documentation and I think\n we can't remove it from the 'Synopsis' porion of the documentation as it doesn't make\n sense (at least to me) to give a description of an option not listed in the synopsis.\n Moreover, we have to state the reason for not supporting it in some place.\n\n I guess the phrase 'no longer supported' is equally communicative. Let me know if that was not\n a right decision.\n\n Documentation/git-branch.txt | 8 ++++----\n builtin/branch.c | 25 +++--------------------\n t/t3200-branch.sh | 47 ++------------------------------------------\n t/t6040-tracking-info.sh | 20 +++++++------------\n 4 files changed, 16 insertions(+), 84 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 81bd0a7b7..948d9c9ef 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -195,10 +195,10 @@ start-point is either a local or remote-tracking branch.\n \tbranch.autoSetupMerge configuration variable is true.\n \n --set-upstream::\n-\tIf specified branch does not exist yet or if `--force` has been\n-\tgiven, acts exactly like `--track`. Otherwise sets up configuration\n-\tlike `--track` would when creating the branch, except that where\n-\tbranch points to is not changed.\n+\tAs this option had confusing syntax it's no longer supported. Please use\n+\t--track or --set-upstream-to instead.\n++\n+Note: This could possibly become an alias of --set-upstream-to in the future.\n \n -u ::\n --set-upstream-to=::\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex a3bd2262b..6e3ea5787 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -557,8 +557,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tOPT__QUIET(&quiet, N_(\"suppress informational messages\")),\n \t\tOPT_SET_INT('t', \"track\", &track, N_(\"set up tracking mode (see git-pull(1))\"),\n \t\t\tBRANCH_TRACK_EXPLICIT),\n-\t\tOPT_SET_INT( 0, \"set-upstream\", &track, N_(\"change upstream info\"),\n-\t\t\tBRANCH_TRACK_OVERRIDE),\n+\t\t{ OPTION_SET_INT, 0, \"set-upstream\", &track, NULL, N_(\"do not use\"),\n+\t\t\tPARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, BRANCH_TRACK_OVERRIDE },\n \t\tOPT_STRING('u', \"set-upstream-to\", &new_upstream, N_(\"upstream\"), N_(\"change the upstream info\")),\n \t\tOPT_BOOL(0, \"unset-upstream\", &unset_upstream, N_(\"Unset the upstream info\")),\n \t\tOPT__COLOR(&branch_use_color, N_(\"use colored output\")),\n@@ -755,8 +755,6 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tstrbuf_release(&buf);\n \t} else if (argc > 0 && argc <= 2) {\n \t\tstruct branch *branch = branch_get(argv[0]);\n-\t\tint branch_existed = 0, remote_tracking = 0;\n-\t\tstruct strbuf buf = STRBUF_INIT;\n \n \t\tif (!strcmp(argv[0], \"HEAD\"))\n \t\t\tdie(_(\"it does not make sense to create 'HEAD' manually\"));\n@@ -768,28 +766,11 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tdie(_(\"-a and -r options to 'git branch' do not make sense with a branch name\"));\n \n \t\tif (track == BRANCH_TRACK_OVERRIDE)\n-\t\t\tfprintf(stderr, _(\"The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to\\n\"));\n+\t\t\tdie(_(\"the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.\"));\n \n-\t\tstrbuf_addf(&buf, \"refs/remotes/%s\", branch->name);\n-\t\tremote_tracking = ref_exists(buf.buf);\n-\t\tstrbuf_release(&buf);\n-\n-\t\tbranch_existed = ref_exists(branch->refname);\n \t\tcreate_branch(argv[0], (argc == 2) ? argv[1] : head,\n \t\t\t force, reflog, 0, quiet, track);\n \n-\t\t/*\n-\t\t * We only show the instructions if the user gave us\n-\t\t * one branch which doesn't exist locally, but is the\n-\t\t * name of a remote-tracking branch.\n-\t\t */\n-\t\tif (argc == 1 && track == BRANCH_TRACK_OVERRIDE &&\n-\t\t !branch_existed && remote_tracking) {\n-\t\t\tfprintf(stderr, _(\"\\nIf you wanted to make '%s' track '%s', do this:\\n\\n\"), head, branch->name);\n-\t\t\tfprintf(stderr, \" git branch -d %s\\n\", branch->name);\n-\t\t\tfprintf(stderr, \" git branch --set-upstream-to %s\\n\", branch->name);\n-\t\t}\n-\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 b54b3ebf3..34f556998 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -606,38 +606,8 @@ test_expect_success 'test --unset-upstream on a particular branch' '\n \ttest_must_fail git config branch.my14.merge\n '\n \n-test_expect_success '--set-upstream shows message when creating a new branch that exists as remote-tracking' '\n-\tgit update-ref refs/remotes/origin/master HEAD &&\n-\tgit branch --set-upstream origin/master 2>actual &&\n-\ttest_when_finished git update-ref -d refs/remotes/origin/master &&\n-\ttest_when_finished git branch -d origin/master &&\n-\tcat >expected <actual &&\n-\ttest_when_finished git branch --unset-upstream master &&\n-\tcat >expected <actual &&\n-\ttest_when_finished git branch --unset-upstream my13 &&\n-\tcat >expected <\"$1\"\ndiff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh\nindex 97a07655a..be78cc4fa 100755\n--- a/t/t6040-tracking-info.sh\n+++ b/t/t6040-tracking-info.sh\n@@ -188,35 +188,29 @@ test_expect_success 'fail to track annotated tags' '\n \ttest_must_fail git checkout heavytrack\n '\n \n-test_expect_success 'setup tracking with branch --set-upstream on existing branch' '\n+test_expect_success '--set-upstream-to does not change branch' '\n \tgit branch from-master master &&\n-\ttest_must_fail git config branch.from-master.merge > actual &&\n-\tgit branch --set-upstream from-master master &&\n-\tgit config branch.from-master.merge > actual &&\n-\tgrep -q \"^refs/heads/master$\" actual\n-'\n-\n-test_expect_success '--set-upstream does not change branch' '\n+\tgit branch --set-upstream-to master from-master &&\n \tgit branch from-master2 master &&\n \ttest_must_fail git config branch.from-master2.merge > actual &&\n \tgit rev-list from-master2 &&\n \tgit update-ref refs/heads/from-master2 from-master2^ &&\n \tgit rev-parse from-master2 >expect2 &&\n-\tgit branch --set-upstream from-master2 master &&\n+\tgit branch --set-upstream-to master from-master2 &&\n \tgit config branch.from-master.merge > actual &&\n \tgit rev-parse from-master2 >actual2 &&\n \tgrep -q \"^refs/heads/master$\" actual &&\n \tcmp expect2 actual2\n '\n \n-test_expect_success '--set-upstream @{-1}' '\n-\tgit checkout from-master &&\n+test_expect_success '--set-upstream-to @{-1}' '\n+\tgit checkout follower &&\n \tgit checkout from-master2 &&\n \tgit config branch.from-master2.merge > expect2 &&\n-\tgit branch --set-upstream @{-1} follower &&\n+\tgit branch --set-upstream-to @{-1} from-master &&\n \tgit config branch.from-master.merge > actual &&\n \tgit config branch.from-master2.merge > actual2 &&\n-\tgit branch --set-upstream from-master follower &&\n+\tgit branch --set-upstream-to follower from-master &&\n \tgit config branch.from-master.merge > expect &&\n \ttest_cmp expect2 actual2 &&\n \ttest_cmp expect actual\n-- \n2.14.0.rc1.434.g6eded367a\n\n"},{"id":"326576","messageId":"20170817025425.6647-3-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170817025425.6647-1-kaarticsivaraam91196@gmail.com","subject":"[PATCH v4 3/3] branch: quote branch/ref names to improve readability","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-17T02:54:25Z","receivedAt":"2017-08-17T02:53:54Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Signed-off-by: Kaartic Sivaraam \n---\n No changes in this one. Sending this just because of the change in the total number\n of commits.\n\n branch.c | 16 ++++++++--------\n 1 file changed, 8 insertions(+), 8 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex ad5a2299b..a40721f3c 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -90,24 +90,24 @@ int install_branch_config(int flag, const char *local, const char *origin, const\n \t\tif (shortname) {\n \t\t\tif (origin)\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track remote branch %s from %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track remote branch %s from %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote branch '%s' from '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote branch '%s' from '%s'.\"),\n \t\t\t\t\t local, shortname, origin);\n \t\t\telse\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track local branch %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track local branch %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track local branch '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track local branch '%s'.\"),\n \t\t\t\t\t local, shortname);\n \t\t} else {\n \t\t\tif (origin)\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track remote ref %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track remote ref %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote ref '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track remote ref '%s'.\"),\n \t\t\t\t\t local, remote);\n \t\t\telse\n \t\t\t\tprintf_ln(rebasing ?\n-\t\t\t\t\t _(\"Branch %s set up to track local ref %s by rebasing.\") :\n-\t\t\t\t\t _(\"Branch %s set up to track local ref %s.\"),\n+\t\t\t\t\t _(\"Branch '%s' set up to track local ref '%s' by rebasing.\") :\n+\t\t\t\t\t _(\"Branch '%s' set up to track local ref '%s'.\"),\n \t\t\t\t\t local, remote);\n \t\t}\n \t}\n-- \n2.14.1.534.g641031ecb\n\n"},{"id":"326623","messageId":"CAN0heSquaXk421sR6Ry59C+er8n26nC93=3KG1wD0xNXZkuiGw@mail.gmail.com","threadId":"46452","inReplyTo":"20170817025425.6647-2-kaarticsivaraam91196@gmail.com","subject":"Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Martin Ågren","fromEmail":"martin.agren@gmail.com","sentAt":"2017-08-17T18:21:26Z","receivedAt":"2017-08-17T18:21:32Z","isPatch":true,"sender":{"key":"martin.agren@gmail.com","avatar":null},"body":"On 17 August 2017 at 04:54, Kaartic Sivaraam\n wrote:\n> Helped-by: Martin Ågren , Junio C Hamano \n> Signed-off-by: Kaartic Sivaraam \n\nI didn't expect a \"Helped-by\", all I did was to give some random\ncomments. :-) I'm not so sure about the comma-separation, that seems to\nbe a first in the project.\n\n> * The option has not yet been removed from the synopsis of the documentation and I think\n> we can't remove it from the 'Synopsis' porion of the documentation as it doesn't make\n> sense (at least to me) to give a description of an option not listed in the synopsis.\n\nThe \"git interpret-trailers --parse\" thread nearby is adding some\noptions without mentioning them in the synopsis [1], and those options\ncan actually be useful, whereas \"--set-upstream\" only results in a fatal\nerror. So I don't know.\n\n> Moreover, we have to state the reason for not supporting it in some place.\n>\n> I guess the phrase 'no longer supported' is equally communicative. Let me know if that was not\n> a right decision.\n\nI think it's ok. Of course, I know exactly what you want to say, and\nwhy, so I'm biased. :-)\n\n[1] https://public-inbox.org/git/20170815102334.qc4w7akl44bti44x@sigill.intra.peff.net/\n"},{"id":"326631","messageId":"xmqqshgqezox.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"CAN0heSquaXk421sR6Ry59C+er8n26nC93=3KG1wD0xNXZkuiGw@mail.gmail.com","subject":"Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-17T19:55:58Z","receivedAt":"2017-08-17T19:56:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Ågren writes:\n\n> On 17 August 2017 at 04:54, Kaartic Sivaraam\n> wrote:\n>> Helped-by: Martin Ågren , Junio C Hamano \n>> Signed-off-by: Kaartic Sivaraam \n>\n> I didn't expect a \"Helped-by\", all I did was to give some random\n> comments. :-) I'm not so sure about the comma-separation, that seems to\n> be a first in the project.\n\nI didn't either ;-) \n\nThe line looks odd so I'll remove it while queuing.\n\nThanks for noticing.\n"},{"id":"326632","messageId":"xmqqo9reezjx.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"20170817025425.6647-2-kaarticsivaraam91196@gmail.com","subject":"Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-17T19:58:58Z","receivedAt":"2017-08-17T19:59:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\n> index 81bd0a7b7..948d9c9ef 100644\n> --- a/Documentation/git-branch.txt\n> +++ b/Documentation/git-branch.txt\n> @@ -195,10 +195,10 @@ start-point is either a local or remote-tracking branch.\n> \tbranch.autoSetupMerge configuration variable is true.\n> \n> --set-upstream::\n> -\tIf specified branch does not exist yet or if `--force` has been\n> -\tgiven, acts exactly like `--track`. Otherwise sets up configuration\n> -\tlike `--track` would when creating the branch, except that where\n> -\tbranch points to is not changed.\n> +\tAs this option had confusing syntax it's no longer supported. Please use\n> +\t--track or --set-upstream-to instead.\n> ++\n> +Note: This could possibly become an alias of --set-upstream-to in the future.\n\nI'll tweak `--track` and `--set-upstream-to` in the updated text\nand remove the 'Note:' thing that does not give any useful\ninformation to the end users while queuing (no need to resend). \n\nThanks.\n"},{"id":"326669","messageId":"69172c47-0af4-4c74-a20b-82da537ad9ee@gmail.com","threadId":"46452","inReplyTo":"xmqqo9reezjx.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-18T02:39:44Z","receivedAt":"2017-08-18T02:38:59Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Friday 18 August 2017 01:28 AM, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n>\n>> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\n>> index 81bd0a7b7..948d9c9ef 100644\n>> --- a/Documentation/git-branch.txt\n>> +++ b/Documentation/git-branch.txt\n>> @@ -195,10 +195,10 @@ start-point is either a local or remote-tracking branch.\n>> \tbranch.autoSetupMerge configuration variable is true.\n>> \n>> --set-upstream::\n>> -\tIf specified branch does not exist yet or if `--force` has been\n>> -\tgiven, acts exactly like `--track`. Otherwise sets up configuration\n>> -\tlike `--track` would when creating the branch, except that where\n>> -\tbranch points to is not changed.\n>> +\tAs this option had confusing syntax it's no longer supported. Please use\n>> +\t--track or --set-upstream-to instead.\n>> ++\n>> +Note: This could possibly become an alias of --set-upstream-to in the future.\n> I'll tweak `--track` and `--set-upstream-to` in the updated text\n> and remove the 'Note:' thing that does not give any useful\n> information to the end users while queuing (no need to resend).\nI thought I explained the reason for adding the note in one of the \nprevious mails.\nHere's the portion of the mail,\n\nOn Monday 14 August 2017 02:20 PM, Kaartic Sivaraam wrote:\n >\n > On Wednesday 09 August 2017 12:03 AM, Martin Ågren wrote:\n >>\n >> Maybe the final note could be removed? Someone who is looking up\n >> --set-upstream because Git just \"crashed\" on them will only want to know\n >> what they should do instead. Our thoughts about the future are perhaps\n >> not that interesting.\n >\n > I thought it's better to document it to avoid people from getting \nsurprised\n > when the options *starts working* again.\n >\n\nI hope that explains the reason.\n\n---\nKaartic\n"},{"id":"326670","messageId":"42219b51-8232-e1ee-9c48-f67ccdcbb4c8@gmail.com","threadId":"46452","inReplyTo":"xmqqshgqezox.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-08-18T02:41:37Z","receivedAt":"2017-08-18T02:40:51Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Friday 18 August 2017 01:25 AM, Junio C Hamano wrote:\n> Martin Ågren writes:\n>\n>> On 17 August 2017 at 04:54, Kaartic Sivaraam\n>> wrote:\n>>> Helped-by: Martin Ågren , Junio C Hamano \n>>> Signed-off-by: Kaartic Sivaraam \n>> I didn't expect a \"Helped-by\", all I did was to give some random\n>> comments. :-) I'm not so sure about the comma-separation, that seems to\n>> be a first in the project.\n> I didn't either ;-)\n>\n> The line looks odd so I'll remove it while queuing.\n>\n> Thanks for noticing.\nI should have been better with my wordings :) How about converting that\nline into two 'Suggestions-by:' or 'Reviewed-by:' ?\n\n\n---\nKaartic\n"},{"id":"326694","messageId":"xmqqr2w8dej6.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"42219b51-8232-e1ee-9c48-f67ccdcbb4c8@gmail.com","subject":"Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-18T16:30:37Z","receivedAt":"2017-08-18T16:30:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> On Friday 18 August 2017 01:25 AM, Junio C Hamano wrote:\n>> Martin Ågren writes:\n>>\n>>> On 17 August 2017 at 04:54, Kaartic Sivaraam\n>>> wrote:\n>>>> Helped-by: Martin Ågren , Junio C Hamano \n>>>> Signed-off-by: Kaartic Sivaraam \n>>> I didn't expect a \"Helped-by\", all I did was to give some random\n>>> comments. :-) I'm not so sure about the comma-separation, that seems to\n>>> be a first in the project.\n>> I didn't either ;-)\n>>\n>> The line looks odd so I'll remove it while queuing.\n>>\n>> Thanks for noticing.\n> I should have been better with my wordings :) How about converting that\n> line into two 'Suggestions-by:' or 'Reviewed-by:' ?\n\nI personally do not think either is needed for those small things we\nsaw in the discussion.\n\nUnless Martin feels strongly about it, that is.\n\nThanks.\n"},{"id":"326695","messageId":"xmqqmv6wdehs.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"69172c47-0af4-4c74-a20b-82da537ad9ee@gmail.com","subject":"Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-18T16:31:27Z","receivedAt":"2017-08-18T16:31:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> On Monday 14 August 2017 02:20 PM, Kaartic Sivaraam wrote:\n>>\n>> On Wednesday 09 August 2017 12:03 AM, Martin Ågren wrote:\n>>>\n>>> Maybe the final note could be removed? Someone who is looking up\n>>> --set-upstream because Git just \"crashed\" on them will only want to know\n>>> what they should do instead. Our thoughts about the future are perhaps\n>>> not that interesting.\n>>\n>> I thought it's better to document it to avoid people from getting \n> surprised\n>> when the options *starts working* again.\n>\n> I hope that explains the reason.\n\nThat is something we can say we _actually_ repurpose the option.\nUntil then, it is merely noise that distracts the users.\n"},{"id":"326700","messageId":"CAN0heSrU-TQnFRYiSF4ubcYXviwVmkxHY7Sf_U7=9i2vzdYp3Q@mail.gmail.com","threadId":"46452","inReplyTo":"xmqqr2w8dej6.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Martin Ågren","fromEmail":"martin.agren@gmail.com","sentAt":"2017-08-18T16:57:07Z","receivedAt":"2017-08-18T16:57:14Z","isPatch":true,"sender":{"key":"martin.agren@gmail.com","avatar":null},"body":"On 18 August 2017 at 18:30, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n>\n>> On Friday 18 August 2017 01:25 AM, Junio C Hamano wrote:\n>>> Martin Ågren writes:\n>>>\n>>>> On 17 August 2017 at 04:54, Kaartic Sivaraam\n>>>> wrote:\n>>>>> Helped-by: Martin Ågren , Junio C Hamano \n>>>>> Signed-off-by: Kaartic Sivaraam \n>>>> I didn't expect a \"Helped-by\", all I did was to give some random\n>>>> comments. :-) I'm not so sure about the comma-separation, that seems to\n>>>> be a first in the project.\n>>> I didn't either ;-)\n>>>\n>>> The line looks odd so I'll remove it while queuing.\n>>>\n>>> Thanks for noticing.\n>> I should have been better with my wordings :) How about converting that\n>> line into two 'Suggestions-by:' or 'Reviewed-by:' ?\n>\n> I personally do not think either is needed for those small things we\n> saw in the discussion.\n>\n> Unless Martin feels strongly about it, that is.\n\nNo, no strong feelings. Thanks.\n"},{"id":"327876","messageId":"xmqqtw081kep.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"1502935475.1710.5.camel@gmail.com","subject":"Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-12T06:49:18Z","receivedAt":"2017-09-12T06:49:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> On Wed, 2017-08-16 at 12:09 -0700, Junio C Hamano wrote:\n>> You said that \"checkout\" does not do a necessary check that is done\n>> in \"branch\", so presumably \"branch\" already has a code to do so that\n>> is not called by the current \"checkout\", right? Then you would add\n>> a new caller in \"checkout\" to trigger the same check that is already\n>> done in \"branch\", but the code \"branch\" uses _might_ be too specific\n>> to the kind of data the current implementation of \"branch\" uses and\n>> it _may_ not be easy to call it directly from \"checkout\" (I didn't\n>> check if that is the case). If so, then the check implemented in\n>> the current \"branch\" may need to be refactored before it can easily\n>> be called from the new caller you would be adding to \"checkout\".\n>> \n>> \n> Thanks. Now I get it. What about doing that check in\n> branch.c::create_branch or branch.c::validate_new_branchname? I guess\n> creating a branch named HEAD isn't that good an idea in any case. Doing\n> the check there might prevent a similar situation in future, I guess.\n> Further \"branch\" and \"checkout\" do call branch.c::create_branch which\n> in turn calls branch.c::validate_new_branchname.\n\nThe above analysis sounds sensible, so it appears that you already\nfound a function that is shared in the two codepaths, and have a\ngood plan to make them consistent?\n\nI was sweeping my mailbox to collect loose ends that haven't been\ntied down, and noticed that this topic does not seem to reach a\nconclusion. Do we want to reboot the effort? Or should we just\nthrow it in the #leftoverbits bin for now?\n\nThanks.\n"},{"id":"327878","messageId":"1505199638.2556.2.camel@gmail.com","threadId":"46452","inReplyTo":"xmqqtw081kep.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-12T07:00:38Z","receivedAt":"2017-09-12T07:00:43Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Tue, 2017-09-12 at 15:49 +0900, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n> \n> > Thanks. Now I get it. What about doing that check in\n> > branch.c::create_branch or branch.c::validate_new_branchname? I guess\n> > creating a branch named HEAD isn't that good an idea in any case. Doing\n> > the check there might prevent a similar situation in future, I guess.\n> > Further \"branch\" and \"checkout\" do call branch.c::create_branch which\n> > in turn calls branch.c::validate_new_branchname.\n> \n> The above analysis sounds sensible, so it appears that you already\n> found a function that is shared in the two codepaths, and have a\n> good plan to make them consistent?\n> \n\nYes, I was just waiting for this reply. In the mean time I thought of\nsending a patch for this but was procrastinating as I felt a little\nlazy.\n\n> I was sweeping my mailbox to collect loose ends that haven't been\n> tied down, and noticed that this topic does not seem to reach a\n> conclusion. Do we want to reboot the effort? Or should we just\n> throw it in the #leftoverbits bin for now?\n> \n\nDon't worry I'll send a patch for this, soon. I mean it :)\n\n-- \nKaartic\n"},{"id":"327881","messageId":"20170912103104.26856-1-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"xmqqtw081kep.fsf@gitster.mtv.corp.google.com","subject":"[PATCH/RFC] branch: strictly don't allow a branch with name 'HEAD'","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-12T10:31:04Z","receivedAt":"2017-09-12T10:31:19Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Allowing a branch with a name 'HEAD' could trigger ambiguity. We could\navoid this by checking for it manually. Moreover this has been done\npartially in 8efb8899c (\"branch: segfault fixes and validation\", 2013-02-23)\nThere was still a way to create a branch with name 'HEAD' by using\n\n $ git checkout -b HEAD\n\nAvoid such loop holes by 'strictly' checking for a branch with name HEAD.\nThe check is referred to as strict because it's done in a place which is\nsupposed to be called to ensure that a new branch name is a valid one.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 3 +++\n builtin/branch.c | 3 ---\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 36541d05c..ea1050649 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -184,6 +184,9 @@ int validate_new_branchname(const char *name, struct strbuf *ref,\n \tif (strbuf_check_branch_ref(ref, name))\n \t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n \n+\tif (!strcmp(name, \"HEAD\"))\n+\t\tdie(_(\"it does not make sense to create 'HEAD' manually\"));\n+\n \tif (!ref_exists(ref->buf))\n \t\treturn 0;\n \telse if (!force && !attr_only)\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 16d391b40..c86348d4c 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -762,9 +762,6 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tint branch_existed = 0, remote_tracking = 0;\n \t\tstruct strbuf buf = STRBUF_INIT;\n \n-\t\tif (!strcmp(argv[0], \"HEAD\"))\n-\t\t\tdie(_(\"it does not make sense to create 'HEAD' manually\"));\n-\n \t\tif (!branch)\n \t\t\tdie(_(\"no such branch '%s'\"), argv[0]);\n \n-- \n2.14.1.1006.g90ad9a07c\n\n"},{"id":"328371","messageId":"20170919071525.9404-1-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"xmqqd18pcysa.fsf@gitster.mtv.corp.google.com","subject":"[RFC PATCH 0/5] branch: improve error messages of branch renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-19T07:15:20Z","receivedAt":"2017-09-19T07:15:50Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"In builtin/branch, the error messages weren't handled directly by the branch\nrenaming function and was left to the other function. Though this avoids\nredundancy this gave unclear error messages in some cases. So, make builtin/branch\ngive more useful error messages.\n\nThe first two patches are preparatory/cleanup patches.\n\nThe third patch refactors a function to make it more usable/understandable(?).\nThis results only in one functional change as noted there. I've tried my best not\nto screw anything up as a consequence of that refactor[note 1]. In case I missed\nsomething, let me know.\n\nThe fourth patch introduces part of the logic needed to improve error messages.\nIt's kept separate to keep things reviewable.\n\nThe fifth patch is the main one which does the improvement of error messages.\n\nThese patches apply on top of 'master' and be found in my fork[2].\n\nNote:\n\n[1]: The Travis CI build did succeed but I don't think we can rely on that a lot\nbecause the test aren't exhaustive (I guess).\nhttps://travis-ci.org/sivaraam/git/builds/277146416\n\n[2]: https://github.com/sivaraam/git/tree/work/branch-move-revamp\n\nKaartic Sivaraam (5):\n builtin/checkout: avoid usage of '!!' for expressions\n branch: document the usage of certain parameters\n branch: cleanup branch name validation\n branch: introduce dont_fail parameter for update validation\n builtin/branch: give more useful error messages when renaming\n\n branch.c | 67 +++++++++++++++++++++++++++++++++++++++---------------\n branch.h | 44 +++++++++++++++++++++++++----------\n builtin/branch.c | 48 +++++++++++++++++++++++++++++++++-----\n builtin/checkout.c | 7 +++---\n t/t3200-branch.sh | 4 ++++\n 5 files changed, 130 insertions(+), 40 deletions(-)\n\n-- \n2.14.1.868.g66c78774b\n\n"},{"id":"328372","messageId":"20170919071525.9404-2-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170919071525.9404-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH 1/5] builtin/checkout: avoid usage of '!!'","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-19T07:15:21Z","receivedAt":"2017-09-19T07:15:53Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Documentation/CodingGuidelines says,\n\n \"Some clever tricks, like using the !! operator with arithmetic\n constructs, can be extremely confusing to others. Avoid them,\n unless there is a compelling reason to use them.\"\n\nThere was a usage for which there's no compelling reason.So, replace\nsuch a usage as with something else that expresses the intent more\nclearly.\n\nSigned-off-by: Kaartic Sivaraam \n---\n I think the expression,\n\n !!opts.new_branch_force\n\n is equivalent to,\n\n opts.new_branch_force != NULL\n\n in all cases. If it's not, let me know.\n\n builtin/checkout.c | 7 +++----\n 1 file changed, 3 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 5c202b7af..76859da9d 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1281,11 +1281,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \n \tif (opts.new_branch) {\n \t\tstruct strbuf buf = STRBUF_INIT;\n+\t\tint force = opts.new_branch_force != NULL;\n \n-\t\topts.branch_exists =\n-\t\t\tvalidate_new_branchname(opts.new_branch, &buf,\n-\t\t\t\t\t\t!!opts.new_branch_force,\n-\t\t\t\t\t\t!!opts.new_branch_force);\n+\t\topts.branch_exists = validate_new_branchname(opts.new_branch, &buf,\n+\t\t\t\t\t\t\t force, force);\n \n \t\tstrbuf_release(&buf);\n \t}\n-- \n2.14.1.868.g66c78774b\n\n"},{"id":"328373","messageId":"20170919071525.9404-3-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170919071525.9404-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH 2/5] branch: document the usage of certain parameters","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-19T07:15:22Z","receivedAt":"2017-09-19T07:15:56Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Documentation for a certain function was incomplete as it didn't say\nwhat certain parameters were used for.\n\nSo, document them for the sake of completeness and easy reference.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.h | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git a/branch.h b/branch.h\nindex b07788558..33b7f5d88 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -15,6 +15,11 @@\n *\n * - reflog creates a reflog for the branch\n *\n+ * - if 'force' is true, clobber_head indicates whether the branch could be\n+ * the current branch; else it has no effect\n+ *\n+ * - quiet suppresses tracking information\n+ *\n * - track causes the new branch to be configured to merge the remote branch\n * that start_name is a tracking branch for (if any).\n */\n-- \n2.14.1.1006.g90ad9a07c\n\n"},{"id":"328374","messageId":"20170919071525.9404-4-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170919071525.9404-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH 3/5] branch: cleanup branch name validation","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-19T07:15:23Z","receivedAt":"2017-09-19T07:15:58Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The function that validates a new branch name was clumsy because,\n\n 1. It did more than just validating the branch name\n\n 2. Despite it's name, it is more often than not used to validate\n existing branch names through the 'force' and 'attr_only'\n parameters (whose names by the way weren't communicative).\n\n 3. The 'attr_only' parameter should have been \"true\" only when\n callers like to update some attribute of the branch and \"false\"\n when they were updating where the branch points to. It was misused\n by callers by setting it to \"true\" (to skip tests) even though they\n were force updating where the current branch was pointing to!\n\n This is an example of spoiling code clarity by making the caller\n rely on how the function is implemented thus making it hard to\n modify/maintain.\n\nThis makes it unclear what the function does at all and would confuse\nthe people who would ever want to it for the first time.\n\nSo, refactor it into a function that validates whether the branch could\nbe updated. This doesn't bear the uncommunicative 'new'. Further replace\nthe 'force' parameter with a 'could_exist' parameter which specifies\nwhether the given branch name could exist or not (it's just a better name\nfor 'force'). Also replace the 'attr_only' with 'clobber_head' which is\na more communicative way of seeing \"If the branch could exist, it's OK if\nit is the current branch\".\n\nSeparate the validation of an existing branch into another function.\nThis (at last!) addresses the NEEDSWORK that was added in fa7993767\n(branch --set-upstream: regression fix, 2011-09-16)\n\nThis refactor has only one functional change. It enforces strictly that\nan existing branch should be updated only with the 'force' switch. So,\nit's no more possible to do,\n\n $ git branch -m master master\n\n(which doesn't seem that useful). This strongly enforces the following\nstatement of the 'git branch' documentation,\n\n \"If exists, -M must be used to force the\n rename to happen.\"\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 41 ++++++++++++++++++++++++++++++-----------\n branch.h | 20 ++++++++------------\n builtin/branch.c | 2 +-\n builtin/checkout.c | 4 ++--\n t/t3200-branch.sh | 4 ++++\n 5 files changed, 45 insertions(+), 26 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 703ded69c..2020dedf6 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -178,18 +178,19 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)\n \treturn 0;\n }\n \n-int validate_new_branchname(const char *name, struct strbuf *ref,\n-\t\t\t int force, int attr_only)\n+int validate_branch_update(const char *name, struct strbuf *ref,\n+\t\t\t int could_exist, int clobber_head)\n {\n \tif (strbuf_check_branch_ref(ref, name))\n \t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n \n \tif (!ref_exists(ref->buf))\n \t\treturn 0;\n-\telse if (!force && !attr_only)\n+\n+\tif (!could_exist)\n \t\tdie(_(\"A branch named '%s' already exists.\"), ref->buf + strlen(\"refs/heads/\"));\n \n-\tif (!attr_only) {\n+\tif (!clobber_head) {\n \t\tconst char *head;\n \t\tstruct object_id oid;\n \n@@ -197,9 +198,29 @@ int validate_new_branchname(const char *name, struct strbuf *ref,\n \t\tif (!is_bare_repository() && head && !strcmp(head, ref->buf))\n \t\t\tdie(_(\"Cannot force update the current branch.\"));\n \t}\n+\n \treturn 1;\n }\n \n+/*\n+ * Validates whether the branch with the given name exists, returning the\n+ * interpreted ref in ref.\n+ *\n+ * This method is invoked if the caller merely wants to know if it is OK\n+ * to change some attribute for the named branch (e.g. tracking upstream).\n+ *\n+ */\n+static void validate_existing_branch(const char *name, struct strbuf *ref)\n+{\n+\tif (strbuf_check_branch_ref(ref, name))\n+\t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n+\n+\tif (ref_exists(ref->buf))\n+\t\treturn;\n+\telse\n+\t\tdie(_(\"branch '%s' doesn't exist\"), name);\n+}\n+\n static int check_tracking_branch(struct remote *remote, void *cb_data)\n {\n \tchar *tracking_branch = cb_data;\n@@ -243,13 +264,11 @@ void create_branch(const char *name, const char *start_name,\n \tif (track == BRANCH_TRACK_EXPLICIT || track == BRANCH_TRACK_OVERRIDE)\n \t\texplicit_tracking = 1;\n \n-\tif (validate_new_branchname(name, &ref, force,\n-\t\t\t\t track == BRANCH_TRACK_OVERRIDE ||\n-\t\t\t\t clobber_head)) {\n-\t\tif (!force)\n-\t\t\tdont_change_ref = 1;\n-\t\telse\n-\t\t\tforcing = 1;\n+\tif (track == BRANCH_TRACK_OVERRIDE) {\n+\t\tvalidate_existing_branch(name, &ref);\n+\t\tdont_change_ref = 1;\n+\t} else {\n+\t\tforcing = validate_branch_update(name, &ref, force, clobber_head);\n \t}\n \n \treal_ref = NULL;\ndiff --git a/branch.h b/branch.h\nindex 33b7f5d88..b4bfff84a 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -28,22 +28,18 @@ void create_branch(const char *name, const char *start_name,\n \t\t int clobber_head, int quiet, enum branch_track track);\n \n /*\n- * Validates that the requested branch may be created, returning the\n- * interpreted ref in ref, force indicates whether (non-head) branches\n- * may be overwritten. A non-zero return value indicates that the force\n- * parameter was non-zero and the branch already exists.\n+ * Validates whether the branch with the given name may be updated (created, renamed etc.,)\n+ * with respect to the given conditions. It returns the interpreted ref in ref.\n *\n- * Contrary to all of the above, when attr_only is 1, the caller is\n- * not interested in verifying if it is Ok to update the named\n- * branch to point at a potentially different commit. It is merely\n- * asking if it is OK to change some attribute for the named branch\n- * (e.g. tracking upstream).\n+ * could_exist indicates whether the branch could exist or not.\n *\n- * NEEDSWORK: This needs to be split into two separate functions in the\n- * longer run for sanity.\n+ * if 'could_exist' is true, clobber_head indicates whether the branch could be the\n+ * current branch; else it has no effect.\n+ *\n+ * A non-zero return value indicates that a branch already exists and can be force updated.\n *\n */\n-int validate_new_branchname(const char *name, struct strbuf *ref, int force, int attr_only);\n+int validate_branch_update(const char *name, struct strbuf *ref, int could_exist, int clobber_head);\n \n /*\n * Remove information about the state of working on the current\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 355f9ef5d..27ddcad97 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -483,7 +483,7 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t */\n \tclobber_head_ok = !strcmp(oldname, newname);\n \n-\tvalidate_new_branchname(newname, &newref, force, clobber_head_ok);\n+\tvalidate_branch_update(newname, &newref, force, clobber_head_ok);\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 76859da9d..2e870ab4b 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1283,8 +1283,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\tstruct strbuf buf = STRBUF_INIT;\n \t\tint force = opts.new_branch_force != NULL;\n \n-\t\topts.branch_exists = validate_new_branchname(opts.new_branch, &buf,\n-\t\t\t\t\t\t\t force, force);\n+\t\topts.branch_exists = validate_branch_update(opts.new_branch, &buf,\n+\t\t\t\t\t\t\t force, force);\n \n \t\tstrbuf_release(&buf);\n \t}\ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex d97164997..ec85cd959 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -137,6 +137,10 @@ test_expect_success 'git branch -m -f o/q o/p should work when o/p exists' '\n \tgit branch -m -f o/q o/p\n '\n \n+test_expect_success 'git branch -m o/o o/o should fail when o/o exists' '\n+\ttest_must_fail git branch -m o/o o/o\n+'\n+\n test_expect_success 'git branch -m q r/q should fail when r exists' '\n \tgit branch q &&\n \tgit branch r &&\n-- \n2.14.1.1006.g90ad9a07c\n\n"},{"id":"328375","messageId":"20170919071525.9404-5-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170919071525.9404-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH 4/5] branch: introduce dont_fail parameter for update validation","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-19T07:15:24Z","receivedAt":"2017-09-19T07:16:01Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"This parameter allows the branch update validation function to\noptionally return a flag specifying the reason for failure, when\nrequested. This allows the caller to know why it was about to die.\nThis allows more useful error messages to be given to the user when\ntrying to rename a branch.\n\nThe flags are specified in the form of an enum and values for success\nflags have been assigned explicitly to clearly express that certain\ncallers rely those values and they cannot be arbitrary.\n\nOnly the logic has been added but no caller has been made to use it, yet.\nSo, no functional changes.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 34 +++++++++++++++++++++++-----------\n branch.h | 23 +++++++++++++++++++++--\n builtin/branch.c | 2 +-\n builtin/checkout.c | 2 +-\n 4 files changed, 46 insertions(+), 15 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 2020dedf6..9dda336a0 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -178,28 +178,40 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)\n \treturn 0;\n }\n \n-int validate_branch_update(const char *name, struct strbuf *ref,\n-\t\t\t int could_exist, int clobber_head)\n+int validate_branch_update(const char *name, struct strbuf *ref, int could_exist,\n+\t\t\t int clobber_head, unsigned dont_fail)\n {\n-\tif (strbuf_check_branch_ref(ref, name))\n-\t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n+\tif (strbuf_check_branch_ref(ref, name)) {\n+\t\tif (dont_fail)\n+\t\t\treturn INVALID_BRANCH_NAME;\n+\t\telse\n+\t\t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n+\t}\n \n \tif (!ref_exists(ref->buf))\n-\t\treturn 0;\n+\t\treturn VALID_BRANCH_NAME;\n \n-\tif (!could_exist)\n-\t\tdie(_(\"A branch named '%s' already exists.\"), ref->buf + strlen(\"refs/heads/\"));\n+\tif (!could_exist) {\n+\t\tif (dont_fail)\n+\t\t\treturn BRANCH_EXISTS;\n+\t\telse\n+\t\t\tdie(_(\"A branch named '%s' already exists.\"), ref->buf + strlen(\"refs/heads/\"));\n+\t}\n \n \tif (!clobber_head) {\n \t\tconst char *head;\n \t\tstruct object_id oid;\n \n \t\thead = resolve_ref_unsafe(\"HEAD\", 0, oid.hash, NULL);\n-\t\tif (!is_bare_repository() && head && !strcmp(head, ref->buf))\n-\t\t\tdie(_(\"Cannot force update the current branch.\"));\n+\t\tif (!is_bare_repository() && head && !strcmp(head, ref->buf)) {\n+\t\t\tif (dont_fail)\n+\t\t\t\treturn CANNOT_FORCE_UPDATE_CURRENT_BRANCH;\n+\t\t\telse\n+\t\t\t\tdie(_(\"Cannot force update the current branch.\"));\n+\t\t}\n \t}\n \n-\treturn 1;\n+\treturn FORCE_UPDATING_BRANCH;\n }\n \n /*\n@@ -268,7 +280,7 @@ void create_branch(const char *name, const char *start_name,\n \t\tvalidate_existing_branch(name, &ref);\n \t\tdont_change_ref = 1;\n \t} else {\n-\t\tforcing = validate_branch_update(name, &ref, force, clobber_head);\n+\t\tforcing = validate_branch_update(name, &ref, force, clobber_head, 0);\n \t}\n \n \treal_ref = NULL;\ndiff --git a/branch.h b/branch.h\nindex 6ada7af59..c6a8a75bb 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -27,6 +27,16 @@ void create_branch(const char *name, const char *start_name,\n \t\t int force, int reflog,\n \t\t int clobber_head, int quiet, enum branch_track track);\n \n+enum branch_validation_result {\n+\t/* Flags that say it's NOT OK to update */\n+\tBRANCH_EXISTS = -3,\n+\tCANNOT_FORCE_UPDATE_CURRENT_BRANCH,\n+\tINVALID_BRANCH_NAME,\n+\t/* Flags that say it's OK to update */\n+\tVALID_BRANCH_NAME = 0,\n+\tFORCE_UPDATING_BRANCH = 1\n+};\n+\n /*\n * Validates whether the branch with the given name may be updated (created, renamed etc.,)\n * with respect to the given conditions. It returns the interpreted ref in ref.\n@@ -36,10 +46,19 @@ void create_branch(const char *name, const char *start_name,\n * if 'could_exist' is true, clobber_head indicates whether the branch could be the\n * current branch else it has no effect.\n *\n- * A non-zero return value indicates that a branch already exists and can be force updated.\n+ * The return values have the following meaning,\n+ *\n+ * - If dont_fail is 0, the function dies in case of failure and returns flags of\n+ * 'validate_result' that specify it is OK to update the branch. The positive\n+ * non-zero flag implies that the branch can be force updated.\n+ *\n+ * - If dont_fail is 1, the function doesn't die in case of failure but returns flags\n+ * of 'validate_result' that specify the reason for failure. The behaviour in case of\n+ * success is same as above.\n *\n */\n-int validate_branch_update(const char *name, struct strbuf *ref, int could_exist, int clobber_head);\n+int validate_branch_update(const char *name, struct strbuf *ref, int could_exist,\n+\t\t\t int clobber_head, unsigned dont_fail);\n \n /*\n * Remove information about the state of working on the current\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 27ddcad97..205c12a11 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -483,7 +483,7 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t */\n \tclobber_head_ok = !strcmp(oldname, newname);\n \n-\tvalidate_branch_update(newname, &newref, force, clobber_head_ok);\n+\tvalidate_branch_update(newname, &newref, force, clobber_head_ok, 0);\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 2e870ab4b..c7e11c352 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1284,7 +1284,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\tint force = opts.new_branch_force != NULL;\n \n \t\topts.branch_exists = validate_branch_update(opts.new_branch, &buf,\n-\t\t\t\t\t\t\t force, force);\n+\t\t\t\t\t\t\t force, force, 0);\n \n \t\tstrbuf_release(&buf);\n \t}\n-- \n2.14.1.868.g66c78774b\n\n"},{"id":"328376","messageId":"20170919071525.9404-6-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170919071525.9404-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH 5/5] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-19T07:15:25Z","receivedAt":"2017-09-19T07:16:03Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"When trying to rename an inexistent branch to an existing branch\nthe rename failed specifying the new branch name exists rather than\nspecifying that the branch trying to be renamed doesn't exist.\n\n $ git branch -m tset master\n fatal: A branch named 'master' already exists.\n\nIt's conventional to report that 'tset' doesn't exist rather than\nreporting that 'master' exists, the same way the 'mv' command does.\n\n $ git branch -m tset master\n fatal: branch 'tset' doesn't exist.\n\nThat has the problem that the error about an existing branch is shown\nonly after the user corrects the error about inexistent branch.\n\n $ git branch -m test master\n fatal: A branch named 'master' already exists.\n\nThis isn't useful either because the user would have corrected this error in\na single go if he had been told this alongside the first error. So, give\nmore useful error messages by giving errors about old branch name and new\nbranch name at the same time. This is possible as the branch update validation\nfunction now returns the reason it was about to die, when requested.\n\n $ git branch -m tset master\n fatal: branch 'tset' doesn't exist, and branch 'master' already exists\n\nNote: Thanks to the strbuf API that made it possible to easily construct\nthe composite error message strings!\n\nSigned-off-by: Kaartic Sivaraam \n---\n builtin/branch.c | 48 ++++++++++++++++++++++++++++++++++++++++++------\n 1 file changed, 42 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 205c12a11..27d24e83d 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -456,25 +456,56 @@ static void reject_rebase_or_bisect_branch(const char *target)\n \tfree_worktrees(worktrees);\n }\n \n+static void get_error_msg(struct strbuf* error_msg, const char* oldname, unsigned old_branch_exists,\n+\t\t\t const char* newname, int new_branch_validation_result)\n+{\n+\tconst char* connector_string = \", and \";\n+\tconst unsigned connector_length = 6;\n+\tunsigned connector_added = 0;\n+\n+\tif (!old_branch_exists) {\n+\t\tstrbuf_addf(error_msg, _(\"branch '%s' doesn't exist\"), oldname);\n+\n+\t\t/* add the 'connector_string' and remove it later if it's not needed */\n+\t\tstrbuf_addstr(error_msg, connector_string);\n+\t\tconnector_added = 1;\n+\t}\n+\n+\tswitch (new_branch_validation_result) {\n+\t\tcase BRANCH_EXISTS:\n+\t\t\tstrbuf_addf(error_msg, _(\"branch '%s' already exists\"), newname);\n+\t\t\tbreak;\n+\t\tcase CANNOT_FORCE_UPDATE_CURRENT_BRANCH:\n+\t\t\tstrbuf_addstr(error_msg, _(\"cannot force update the current branch\"));\n+\t\t\tbreak;\n+\t\tcase INVALID_BRANCH_NAME:\n+\t\t\tstrbuf_addf(error_msg, _(\"branch name '%s' is invalid\"), newname);\n+\t\t\tbreak;\n+\t\tcase VALID_BRANCH_NAME:\n+\t\tcase FORCE_UPDATING_BRANCH:\n+\t\t\tif(connector_added)\n+\t\t\t\tstrbuf_remove(error_msg, error_msg->len-connector_length, connector_length);\n+\t}\n+}\n+\n static void rename_branch(const char *oldname, const char *newname, int force)\n {\n \tstruct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n \tstruct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n \tint recovery = 0;\n \tint clobber_head_ok;\n+\tstruct strbuf error_msg = STRBUF_INIT, empty = STRBUF_INIT;\n \n \tif (!oldname)\n \t\tdie(_(\"cannot rename the current branch while not on any.\"));\n \n-\tif (strbuf_check_branch_ref(&oldref, oldname)) {\n+\tif (strbuf_check_branch_ref(&oldref, oldname) && ref_exists(oldref.buf))\n+\t{\n \t\t/*\n \t\t * Bad name --- this could be an attempt to rename a\n \t\t * ref that we used to allow to be created by accident.\n \t\t */\n-\t\tif (ref_exists(oldref.buf))\n-\t\t\trecovery = 1;\n-\t\telse\n-\t\t\tdie(_(\"Invalid branch name: '%s'\"), oldname);\n+\t\trecovery = 1;\n \t}\n \n \t/*\n@@ -483,7 +514,10 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t */\n \tclobber_head_ok = !strcmp(oldname, newname);\n \n-\tvalidate_branch_update(newname, &newref, force, clobber_head_ok, 0);\n+\tget_error_msg(&error_msg, oldname, ref_exists(oldref.buf),\n+\t\t\tnewname, validate_branch_update(newname, &newref, force, clobber_head_ok, 1));\n+\tif (strbuf_cmp(&error_msg, &empty))\n+\t\tdie(\"%s\", error_msg.buf);\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \n@@ -509,6 +543,8 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t\tdie(_(\"Branch is renamed, but update of config-file failed\"));\n \tstrbuf_release(&oldsection);\n \tstrbuf_release(&newsection);\n+\tstrbuf_release(&error_msg);\n+\tstrbuf_release(&empty);\n }\n \n static GIT_PATH_FUNC(edit_description, \"EDIT_DESCRIPTION\")\n-- \n2.14.1.868.g66c78774b\n\n"},{"id":"328378","messageId":"da5038e1-4d45-881b-3791-746987112aa7@gmail.com","threadId":"46452","inReplyTo":"20170919071525.9404-6-kaarticsivaraam91196@gmail.com","subject":"[RFC SAMPLE] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-19T08:41:29Z","receivedAt":"2017-09-19T08:41:40Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The patch series results in a change in output as specified below. Only \nfew cases\nhave been shown here to keep it short. The output for other cases are \nsimilar.\n\n$ git branch\n* master\n foo\n bar\n\nBefore patch,\n\n$ # Trying to rename non-existent branch\n$ git branch -m hypothet no_such_branch\nerror: refname refs/heads/hypothet not found\nfatal: Branch rename failed\n\n\n$ # Trying to rename non-existent branch into existing one\n$ git branch -m hypothet master\nerror: refname refs/heads/hypothet not found\nfatal: Branch rename failed\n\n\n$ # Trying to force update current branch\n$ git branch -M foo master\nfatal: Cannot force update the current branch.\n\n$ # Trying to force rename an in-existent branch with an invalid name\n$ git branch -M hypothet ?123\nfatal: '?123' is not a valid branch name.\n\n\nAfter patch,\n\n$ # Trying to rename non-existent branch\n$ git branch -m hypothet no_such_branch\nfatal: branch 'hypothet' doesn't exist\n\n$ # Trying to rename non-existent branch into existing one\n$ git branch -m hypothet master\nfatal: branch 'hypothet' doesn't exist, and branch 'master' already exists\n\n\n$ # Trying to force update current branch\n$ git branch -M foo master\nfatal: cannot force update the current branch\n\n$ # Trying to force rename an in-existent branch with an invalid name\n$ git branch -M hypothet ?123\nfatal: branch 'hypothet' doesn't exist, and branch name '?123' is invalid\n\n"},{"id":"328380","messageId":"78e82320-2fbd-3382-c618-ccdc066bc77b@gmail.com","threadId":"46452","inReplyTo":"da5038e1-4d45-881b-3791-746987112aa7@gmail.com","subject":"Re: [RFC SAMPLE] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-19T09:33:26Z","receivedAt":"2017-09-19T09:33:40Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Sorry, the email client seems to have crapped up the formatting. In case\nit looks difficult to follow, let me know so that I could send a better \nversion.\n\n---\nKaartic\n"},{"id":"328443","messageId":"xmqq8thaow8f.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"20170919071525.9404-2-kaarticsivaraam91196@gmail.com","subject":"Re: [RFC PATCH 1/5] builtin/checkout: avoid usage of '!!'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-20T04:00:16Z","receivedAt":"2017-09-20T04:00:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> There was a usage for which there's no compelling reason.So, replace\n> such a usage as with something else that expresses the intent more\n> clearly.\n\nI actually think this is a good example of the exception-rule. The\nfunction wants to take true or false in \"int\", and the caller has a\npointer. And !!ptr is a shorter and more established way than ptr\n!= NULL to turn non-NULL ness into an int boolean, without having to\neither repeat or introducing an otherwise unnecessary temporary.\n"},{"id":"328444","messageId":"xmqq4lryovnm.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"20170919071525.9404-3-kaarticsivaraam91196@gmail.com","subject":"Re: [RFC PATCH 2/5] branch: document the usage of certain parameters","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-20T04:12:45Z","receivedAt":"2017-09-20T04:12:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> Documentation for a certain function was incomplete as it didn't say\n> what certain parameters were used for.\n>\n> So, document them for the sake of completeness and easy reference.\n\nThanks.\n\n> @@ -15,6 +15,11 @@\n> *\n> * - reflog creates a reflog for the branch\n> *\n> + * - if 'force' is true, clobber_head indicates whether the branch could be\n> + * the current branch; else it has no effect\n\nEverybody else in this list begins with what it is describing for\neasy eyeballing. Can you make this match that pattern?\n\nAlso, what does \"could be\" mean in that sentence? Is the caller\ntelling the function \"how, I do not exactly know if that is the\ncase, but the branch I am asking to create you might be the same\nbranch as what is currently checked out, so be extra careful\"?\n\nOr is the comment telling a potential caller that it can pass true\nto signal that create_branch() is allowed to (re)\"create\" the branch\nthat is already checked out (hence it already exists)?\n\nI think the confusing statement above arises because an assumption\nis unstated there. If the reader knows \"Even with force, calling\ncreate_branch() on the currently checked out branch is normally\nforbidden\", then the reader can guess your \"could\" mean the latter.\n\n\t- clobber_head_ok allows the currently checked out (hence\n existing) branch to be overwritten; without force, it has\n no effect.\n\nperhaps? As the underlying helper calls it clobber_head_ok, and\nthat name is more clearly expresses that this is a permission than\nthe current name, I chose to add _ok to the above example, but if\nyou are to take the suggestion, you'd need to also update the names\nin the declaration, too.\n\n> + *\n> + * - quiet suppresses tracking information\n> + *\n> * - track causes the new branch to be configured to merge the remote branch\n> * that start_name is a tracking branch for (if any).\n> */\n"},{"id":"328445","messageId":"xmqqzi9qngq9.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"20170919071525.9404-4-kaarticsivaraam91196@gmail.com","subject":"Re: [RFC PATCH 3/5] branch: cleanup branch name validation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-20T04:20:30Z","receivedAt":"2017-09-20T04:20:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> -int validate_new_branchname(const char *name, struct strbuf *ref,\n> -\t\t\t int force, int attr_only)\n> +int validate_branch_update(const char *name, struct strbuf *ref,\n> +\t\t\t int could_exist, int clobber_head)\n\n\"update\" to me means something already exists and the caller is\nasking this function if it is OK to update it, but is that what this\nfunction is used for? I do not find the original name too bad, but\nif I were renaming it, I'd call it ok_to_create_branch(), with the\nunderstanding that forcing a recreation of an existing branch falls\ninto the wider definition of \"create\".\n\nAlso I'd avoid \"could\", which can be taken as an optimization hint\n(i.e. \"you usually do not have to worry about this thing to already\nexist, but I am telling you that for this one call that is not the\ncase and you need to be a bit more careful by spending extra cycles\nto see if it is and deal with the situation accordingly if it indeed\nis\"), and use \"ok\" as part of the name for the parameter (or flip\nthe meaning of it and say \"create_only\" or something).\n"},{"id":"328458","messageId":"e07a613e-8b69-e382-777b-b5797270ecaf@gmail.com","threadId":"46452","inReplyTo":"xmqq8thaow8f.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH 1/5] builtin/checkout: avoid usage of '!!'","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-20T08:09:41Z","receivedAt":"2017-09-20T08:10:09Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wednesday 20 September 2017 09:30 AM, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n>\n>> There was a usage for which there's no compelling reason.So, replace\n>> such a usage as with something else that expresses the intent more\n>> clearly.\n> I actually think this is a good example of the exception-rule. The\n> function wants to take true or false in \"int\", and the caller has a\n> pointer. And !!ptr is a shorter and more established way than ptr\n> != NULL to turn non-NULL ness into an int boolean, without having to\n> either repeat or introducing an otherwise unnecessary temporary.\n\nThough !!ptr might might be a shorter way to turn a pointer into an\nint boolean I think the documentation says pretty well why we\nshouldn't be using it,\n\n         \"..  can be extremely confusing to others\".\n\nShould I drop this treating is an exception rule (or) should I keep this\nback?\n\nThanks,\nKaartic\n"},{"id":"328459","messageId":"d4e61e9b-e7ed-3565-6017-128b2fe3b72a@gmail.com","threadId":"46452","inReplyTo":"xmqq4lryovnm.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH 2/5] branch: document the usage of certain parameters","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-20T09:01:58Z","receivedAt":"2017-09-20T09:02:11Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wednesday 20 September 2017 09:42 AM, Junio C Hamano wrote:\n>\n>> @@ -15,6 +15,11 @@\n>> *\n>> * - reflog creates a reflog for the branch\n>> *\n>> + * - if 'force' is true, clobber_head indicates whether the branch could be\n>> + * the current branch; else it has no effect\n> Everybody else in this list begins with what it is describing for\n> easy eyeballing. Can you make this match that pattern?\n\nSure!\n\n> Also, what does \"could be\" mean in that sentence? Is the caller\n> telling the function \"how, I do not exactly know if that is the\n> case, but the branch I am asking to create you might be the same\n> branch as what is currently checked out, so be extra careful\"?\n>\n> Or is the comment telling a potential caller that it can pass true\n> to signal that create_branch() is allowed to (re)\"create\" the branch\n> that is already checked out (hence it already exists)?\n\nThanks. I didn't anticipate the possibility of misinterpretation.\n\n> I think the confusing statement above arises because an assumption\n> is unstated there. If the reader knows \"Even with force, calling\n> create_branch() on the currently checked out branch is normally\n> forbidden\", then the reader can guess your \"could\" mean the latter.\n>\n> \t- clobber_head_ok allows the currently checked out (hence\n> existing) branch to be overwritten; without force, it has\n> no effect.\n>\n> perhaps?\n\nSounds better. Will use it.\n\n> ... As the underlying helper calls it clobber_head_ok, and\n> that name is more clearly expresses that this is a permission than\n> the current name, I chose to add _ok to the above example, but if\n> you are to take the suggestion, you'd need to also update the names\n> in the declaration, too.\n\nYes.\n\nOne thing I haven't done suspecting it wouldn't be encouraged is,\nrearranging the order of parameters to group the related ones\ntogether i.e., something like,\n\ndiff --git a/branch.c b/branch.c\nindex 703ded69c..0ea105b55 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -229,7 +229,7 @@ N_(\"\\n\"\n \"\\\"git push -u\\\" to set the upstream config as you push.\");\n \n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog, int clobber_head,\n+\t\t int force, int clobber_head_ok, int reflog,\n \t\t int quiet, enum branch_track track)\n {\n \tstruct commit *commit;\n@@ -245,7 +245,7 @@ void create_branch(const char *name, const char *start_name,\n \n \tif (validate_new_branchname(name, &ref, force,\n \t\t\t\t track == BRANCH_TRACK_OVERRIDE ||\n-\t\t\t\t clobber_head)) {\n+\t\t\t\t clobber_head_ok)) {\n \t\tif (!force)\n \t\t\tdont_change_ref = 1;\n \t\telse\ndiff --git a/branch.h b/branch.h\nindex 33b7f5d88..c62763ac9 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -13,10 +13,10 @@\n *\n * - force enables overwriting an existing (non-head) branch\n *\n- * - reflog creates a reflog for the branch\n+ * - clobber_head_ok allows the currently checked out (hence existing)\n+ * branch to be overwritten; without 'force', it has no effect.\n *\n- * - if 'force' is true, clobber_head indicates whether the branch could be\n- * the current branch; else it has no effect\n+ * - reflog creates a reflog for the branch\n *\n * - quiet suppresses tracking information\n *\n@@ -24,8 +24,8 @@\n * that start_name is a tracking branch for (if any).\n */\n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog,\n-\t\t int clobber_head, int quiet, enum branch_track track);\n+\t\t int force, int clobber_head_ok,\n+\t\t int reflog, int quiet, enum branch_track track);\n \n /*\n * Validates that the requested branch may be created, returning the\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 355f9ef5d..62c311478 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -773,7 +773,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tdie(_(\"the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.\"));\n \n \t\tcreate_branch(argv[0], (argc == 2) ? argv[1] : head,\n-\t\t\t force, reflog, 0, quiet, track);\n+\t\t\t force, 0, reflog, quiet, track);\n \n \t} else\n \t\tusage_with_options(builtin_branch_usage, options);\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 76859da9d..116d4709d 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -641,8 +641,8 @@ static void update_refs_for_switch(const struct checkout_opts *opts,\n \t\telse\n \t\t\tcreate_branch(opts->new_branch, new->name,\n \t\t\t\t opts->new_branch_force ? 1 : 0,\n-\t\t\t\t opts->new_branch_log,\n \t\t\t\t opts->new_branch_force ? 1 : 0,\n+\t\t\t\t opts->new_branch_log,\n \t\t\t\t opts->quiet,\n \t\t\t\t opts->track);\n \t\tnew->name = opts->new_branch;\n\n\nCan I do this or should I keep the patch focused around the\ndocumentation part alone?\n\n---\nKaartic\n"},{"id":"328461","messageId":"fbe3d3e2-a14c-fe7c-7e5d-c24789b249ca@gmail.com","threadId":"46452","inReplyTo":"e07a613e-8b69-e382-777b-b5797270ecaf@gmail.com","subject":"Re: [RFC PATCH 1/5] builtin/checkout: avoid usage of '!!'","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-20T11:26:48Z","receivedAt":"2017-09-20T11:26:59Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Wait, I missed a contradiction here.\n\nOn Wednesday 20 September 2017 09:30 AM, Junio C Hamano wrote:\n> ....  And !!ptr is a shorter and more established way than ptr\n> != NULL to turn non-NULL ness into an int boolean,\n\nDocumentation/SubmittingPatches says:\n\n>  - Some clever tricks, like using the !! operator with arithmetic\n>    constructs, can be extremely confusing to others.\nIf !!ptr is a **more established way** to then why should it confuse \nothers. Of course,\n!!ptr was stated as an \"exception-rule\" where ptr is a pointer (possibly \nNULL). That makes\nme wonder in what case is it \"confusing\" at all?\n\n---\nKaartic\n"},{"id":"328462","messageId":"1d620d52-5326-269a-8710-160b75fada81@gmail.com","threadId":"46452","inReplyTo":"xmqqzi9qngq9.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH 3/5] branch: cleanup branch name validation","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-20T12:04:39Z","receivedAt":"2017-09-20T12:04:50Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wednesday 20 September 2017 09:50 AM, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n>\n>> -int validate_new_branchname(const char *name, struct strbuf *ref,\n>> -\t\t\t int force, int attr_only)\n>> +int validate_branch_update(const char *name, struct strbuf *ref,\n>> +\t\t\t int could_exist, int clobber_head)\n> \"update\" to me means something already exists and the caller is\n> asking this function if it is OK to update it, but is that what this\n> function is used for?\n\nOf course not. I couldn't come up with better names.\n\n> I do not find the original name too bad, but\n> if I were renaming it, I'd call it ok_to_create_branch(), with the\n> understanding that forcing a recreation of an existing branch falls\n> into the wider definition of \"create\".\n\nThanks for giving a better alternative. Sounds catchy. How about\n`validate_branch_creation`? For some unknown reason, I seem to\nlike to have the word \"validate\" in the name. If that's not ok, I'll\nuse the suggested name.\n\n> Also I'd avoid \"could\", which can be taken as an optimization hint\n> (i.e. \"you usually do not have to worry about this thing to already\n> exist, but I am telling you that for this one call that is not the\n> case and you need to be a bit more careful by spending extra cycles\n> to see if it is and deal with the situation accordingly if it indeed\n> is\"), and use \"ok\" as part of the name for the parameter (or flip\n> the meaning of it and say \"create_only\" or something).\n\nWill fix that.\n\n---\nKaartic\n"},{"id":"328467","messageId":"aaffe492-75bc-c898-1ab2-271f9f8c9e17@gmail.com","threadId":"46452","inReplyTo":"xmqqzi9qngq9.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH 3/5] branch: cleanup branch name validation","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-20T14:52:32Z","receivedAt":"2017-09-20T14:52:43Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wednesday 20 September 2017 09:50 AM, Junio C Hamano wrote:\n> Also I'd avoid \"could\", which can be taken as an optimization hint\n> (i.e. \"you usually do not have to worry about this thing to already\n> exist, but I am telling you that for this one call that is not the\n> case and you need to be a bit more careful by spending extra cycles\n> to see if it is and deal with the situation accordingly if it indeed\n> is\"), and use \"ok\" as part of the name for the parameter (or flip\n> the meaning of it and say \"create_only\" or something).\n\nConsider I'm gonna replace 'force' with a parameter that has the flipped\nmeaning. Does 'shouldnt_exist' seem to be a good name for this new\nparameter?\n"},{"id":"328502","messageId":"CAGZ79kYMagCFS765NtOBDxDJYaXMyA4-=xxi3JMxbga638b6Yg@mail.gmail.com","threadId":"46452","inReplyTo":"20170919071525.9404-6-kaarticsivaraam91196@gmail.com","subject":"Re: [RFC PATCH 5/5] builtin/branch: give more useful error messages when renaming","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-09-20T20:57:38Z","receivedAt":"2017-09-20T20:57:45Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Sep 19, 2017 at 12:15 AM, Kaartic Sivaraam\n wrote:\n> When trying to rename an inexistent branch to an existing branch\n> the rename failed specifying the new branch name exists rather than\n> specifying that the branch trying to be renamed doesn't exist.\n>\n> $ git branch -m tset master\n> fatal: A branch named 'master' already exists.\n>\n> It's conventional to report that 'tset' doesn't exist rather than\n> reporting that 'master' exists, the same way the 'mv' command does.\n>\n> $ git branch -m tset master\n\nThis is not the 'mv' command as promised? So this is just\nto demonstrate the (still fictional) better error message?\nMaybe use a real 'mv' command here?\n\n> fatal: branch 'tset' doesn't exist.\n>\n> That has the problem that the error about an existing branch is shown\n> only after the user corrects the error about inexistent branch.\n>\n> $ git branch -m test master\n> fatal: A branch named 'master' already exists.\n>\n> This isn't useful either because the user would have corrected this error in\n> a single go if he had been told this alongside the first error. So, give\n> more useful error messages by giving errors about old branch name and new\n> branch name at the same time. This is possible as the branch update validation\n> function now returns the reason it was about to die, when requested.\n>\n> $ git branch -m tset master\n> fatal: branch 'tset' doesn't exist, and branch 'master' already exists\n>\n> Note: Thanks to the strbuf API that made it possible to easily construct\n> the composite error message strings!\n\nThis shall be read as an apology to all translators out there. ;)\nPlaying sentence lego in source code is not optimal, as other\nlanguages are very different and you cannot assume even simplest\nthings about them (because of their variety).\n\nIn this case it might not be as bad, because we're providing a\nwhole sentence per _(translatable) unit.\n"},{"id":"328519","messageId":"xmqqlgl8n8fn.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"fbe3d3e2-a14c-fe7c-7e5d-c24789b249ca@gmail.com","subject":"Re: [RFC PATCH 1/5] builtin/checkout: avoid usage of '!!'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-21T01:31:56Z","receivedAt":"2017-09-21T01:32:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> Wait, I missed a contradiction here.\n> ..\n> Documentation/SubmittingPatches says:\n>\n>> - Some clever tricks, like using the !! operator with arithmetic\n>> constructs, can be extremely confusing to others.\n\nWhat does \"with arithmetic constructs\" mean? Would it refer to\nthings like\n\n\t!!i != !!(j + 3)\n\nthat unnecessarily obfuscates what is going on?\n\nThe primary reason why !!ptr is good in the code that this patch\ntouches is because what is doubly negated is a pointer, not an\ninteger or other things. The called function does *not* limit its\ninput to 0 or 1 (it wants 0 for false and everything else for true),\nso we wouldn't be doing !!i if what we are passing is already an\ninteger. But we cannot just pass a pointer to such a parameter\nwithout getting the compiler upset.\n\n\n"},{"id":"328520","messageId":"xmqqh8vwn8ch.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"d4e61e9b-e7ed-3565-6017-128b2fe3b72a@gmail.com","subject":"Re: [RFC PATCH 2/5] branch: document the usage of certain parameters","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-21T01:33:50Z","receivedAt":"2017-09-21T01:33:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> Can I do this or should I keep the patch focused around the\n> documentation part alone?\n\nYou can do both if you wanted to but not in a same patch that makes\nthe result noisier than it needs to.\n"},{"id":"328521","messageId":"xmqqd16kn86t.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"1d620d52-5326-269a-8710-160b75fada81@gmail.com","subject":"Re: [RFC PATCH 3/5] branch: cleanup branch name validation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-21T01:37:14Z","receivedAt":"2017-09-21T01:37:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> Thanks for giving a better alternative. Sounds catchy. How about\n> `validate_branch_creation`?\n\nI do not know what you meant by \"catchy\", but \"git grep ok_to_\" will\ntell you that ok-to-$do-something is quite an establish phrasing (if\nI thought it was a bad way to name it, I would have explicitly said\nso).\n\n\n"},{"id":"328728","messageId":"2e91fd2e-3c8a-ff93-ff6f-4a30191d1249@gmail.com","threadId":"46452","inReplyTo":"CAGZ79kYMagCFS765NtOBDxDJYaXMyA4-=xxi3JMxbga638b6Yg@mail.gmail.com","subject":"Re: [RFC PATCH 5/5] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-23T10:50:35Z","receivedAt":"2017-09-23T10:50:50Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Thursday 21 September 2017 02:27 AM, Stefan Beller wrote:\n>\n>> It's conventional to report that 'tset' doesn't exist rather than\n>> reporting that 'master' exists, the same way the 'mv' command does.\n>>\n>> $ git branch -m tset master\n> This is not the 'mv' command as promised? So this is just\n> to demonstrate the (still fictional) better error message?\n\nYes\n\n> Maybe use a real 'mv' command here?\n\nIt didn't want to do that to avoid preserve continuity. I'll change the \ncommit\nmessage a little to fix this.\n\n---\nKaartic\n"},{"id":"328730","messageId":"de378f54-1c6f-327e-3f61-f8b215cfe203@gmail.com","threadId":"46452","inReplyTo":"xmqqlgl8n8fn.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH 1/5] builtin/checkout: avoid usage of '!!'","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-23T12:17:09Z","receivedAt":"2017-09-23T12:17:21Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Thursday 21 September 2017 07:01 AM, Junio C Hamano wrote:\n> What does \"with arithmetic constructs\" mean? Would it refer to\n> things like\n>\n> \t!!i != !!(j + 3)\n>\n> that unnecessarily obfuscates what is going on?\n\nThanks that clears the confusion because I haven't seen constructs\nlike this before (who would even do something like this?)\n\n> The primary reason why !!ptr is good in the code that this patch\n> touches is because what is doubly negated is a pointer, not an\n> integer or other things. The called function does *not* limit its\n> input to 0 or 1 (it wants 0 for false and everything else for true),\n> so we wouldn't be doing !!i if what we are passing is already an\n> integer. But we cannot just pass a pointer to such a parameter\n> without getting the compiler upset.\n>\n>\n\nDone. So I'll drop this patch.\n\n---\nKaartic\n"},{"id":"328731","messageId":"811bc0ca-b503-2917-f985-e66538f7219c@gmail.com","threadId":"46452","inReplyTo":"xmqqd16kn86t.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH 3/5] branch: cleanup branch name validation","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-09-23T12:52:06Z","receivedAt":"2017-09-23T12:52:21Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Thursday 21 September 2017 07:07 AM, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n>\n>> Thanks for giving a better alternative. Sounds catchy. How about\n>> `validate_branch_creation`?\n> I do not know what you meant by \"catchy\",\n\nI was intending that 'ok_to_create_branch' was a \"nice alternative\" when I\nsaid catchy (I should better be more clear in the future).\n\n> but \"git grep ok_to_\" will\n> tell you that ok-to-$do-something is quite an establish phrasing (if\n> I thought it was a bad way to name it, I would have explicitly said\n> so).\n>\n\nWell, it might be an established phrase but I feel that the 'ok_to' part \nof the\nname implies that it returns some sort of boolean value ('ok' or 'not ok')\nrather than the status. This doesn't seem to be the case for the\n`validate_new_branchname` which returns values only upon success\nand dies in case of failure (Note: only the PATCH 4/5 in the series adds \nthe\nlogic to return a value in case of failure; when requested). So, I find the\nname \"ok_to_create_branch\" to be less communicative. Though I don't find\nthe name \"validate_branch_creation\" to be conveys this meaning any better;\nI thought of using it as it doesn't seem to be implying a boolean return \nvalue.\n\n---\nKaartic\n"},{"id":"328818","messageId":"20170925082024.2691-1-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170919071525.9404-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH v2 0/5] Give more useful error messages when renaming a branch","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-09-25T08:20:19Z","receivedAt":"2017-09-25T08:20:45Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":" [1/5] and [2/5] - cleanup patches\n [3/5] - refactor of a function that seemed a little unintuitive\n [4/5] - just a preparatory step adding part of the logic\n [5/5] - main patch that tries to improve the error messages\n\nChanges in v2:\n\n - dropped [1/5] of v1\n \n [1/5]\n\n - incroporated suggestions of Junio\n\n [2/5]\n\n - new in this series\n - just a little thing I thought could improve things\n\n [3/5]\n\n - used the name 'validate_branch_creation' for the refactor\n instead of 'validate_branch_update'\n\n - changed the parameter names\n\n [5/5]\n\n - In v1 I added the connector string and removed it when it wasn't \n necessary. It's not possible to do that as that string has to be\n translated too and it won't have the same number of characters in\n other languages. So, I switched to adding the connector only when\n needed. Though this seems to introduce some redundancy, I find it\n to be the only reliable way. \n\n - tweaked commit message a little as suggested by Stefan\n\nThere is no change in the error messages themselves. So the sample input\noutput interaction sent for v1 still holds.\n\nThis series applies on top of 'master' and can be found in my fork[1].\nIn case you were wondering, the Travis-CI tests did pass.\n\n[1]: https://github.com/sivaraam/git/tree/work/branch-move-revamp\n[2]: https://travis-ci.org/sivaraam/git/builds/279199977\n\nKaartic Sivaraam (5):\n branch: improve documentation and naming of certain parameters\n branch: re-order function arguments to group related arguments\n branch: cleanup branch name validation\n branch: introduce dont_fail parameter for create validation\n builtin/branch: give more useful error messages when renaming\n\n branch.c | 69 +++++++++++++++++++++++++++++++++++++++---------------\n branch.h | 53 ++++++++++++++++++++++++++++++-----------\n builtin/branch.c | 43 ++++++++++++++++++++++++++++------\n builtin/checkout.c | 8 +++----\n t/t3200-branch.sh | 4 ++++\n 5 files changed, 133 insertions(+), 44 deletions(-)\n\n-- \n2.14.1.935.ge2b2bcd8a\n\n"},{"id":"328819","messageId":"20170925082024.2691-2-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170925082024.2691-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH v2 1/5] branch: improve documentation and naming of certain parameters","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-09-25T08:20:20Z","receivedAt":"2017-09-25T08:20:50Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Documentation for a certain function was incomplete as it didn't say\nwhat certain parameters were used for. Further a parameter name wasn't\nvery communicative.\n\nSo, add missing documentation for the sake of completeness and easy\nreference. Also, rename the concerned parameter to make it's name more\ncommunicative.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 4 ++--\n branch.h | 7 ++++++-\n 2 files changed, 8 insertions(+), 3 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 703ded69c..8d4360aa5 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -229,7 +229,7 @@ N_(\"\\n\"\n \"\\\"git push -u\\\" to set the upstream config as you push.\");\n \n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog, int clobber_head,\n+\t\t int force, int reflog, int clobber_head_ok,\n \t\t int quiet, enum branch_track track)\n {\n \tstruct commit *commit;\n@@ -245,7 +245,7 @@ void create_branch(const char *name, const char *start_name,\n \n \tif (validate_new_branchname(name, &ref, force,\n \t\t\t\t track == BRANCH_TRACK_OVERRIDE ||\n-\t\t\t\t clobber_head)) {\n+\t\t\t\t clobber_head_ok)) {\n \t\tif (!force)\n \t\t\tdont_change_ref = 1;\n \t\telse\ndiff --git a/branch.h b/branch.h\nindex b07788558..cb6411f84 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -15,12 +15,17 @@\n *\n * - reflog creates a reflog for the branch\n *\n+ * - clobber_head_ok allows the currently checked out (hence existing)\n+ * branch to be overwritten; without 'force', it has no effect.\n+ *\n+ * - quiet suppresses tracking information\n+ *\n * - track causes the new branch to be configured to merge the remote branch\n * that start_name is a tracking branch for (if any).\n */\n void create_branch(const char *name, const char *start_name,\n \t\t int force, int reflog,\n-\t\t int clobber_head, int quiet, enum branch_track track);\n+\t\t int clobber_head_ok, int quiet, enum branch_track track);\n \n /*\n * Validates that the requested branch may be created, returning the\n-- \n2.14.1.935.ge2b2bcd8a\n\n"},{"id":"328820","messageId":"20170925082024.2691-3-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170925082024.2691-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH v2 2/5] branch: re-order function arguments to group related arguments","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-09-25T08:20:21Z","receivedAt":"2017-09-25T08:20:53Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The ad-hoc patches to add new arguments to a function when needed\nresulted in the related arguments not being close to each other.\nThis misleads the person reading the code to believe that there isn't\nmuch relation between those arguments while it's not the case.\n\nSo, re-order the arguments to keep the related arguments close to each\nother.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 2 +-\n branch.h | 4 ++--\n builtin/branch.c | 2 +-\n builtin/checkout.c | 2 +-\n 4 files changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 8d4360aa5..0ea105b55 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -229,7 +229,7 @@ N_(\"\\n\"\n \"\\\"git push -u\\\" to set the upstream config as you push.\");\n \n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog, int clobber_head_ok,\n+\t\t int force, int clobber_head_ok, int reflog,\n \t\t int quiet, enum branch_track track)\n {\n \tstruct commit *commit;\ndiff --git a/branch.h b/branch.h\nindex cb6411f84..a6740bb9f 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -24,8 +24,8 @@\n * that start_name is a tracking branch for (if any).\n */\n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog,\n-\t\t int clobber_head_ok, int quiet, enum branch_track track);\n+\t\t int force, int clobber_head_ok,\n+\t\t int reflog, int quiet, enum branch_track track);\n \n /*\n * Validates that the requested branch may be created, returning the\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 355f9ef5d..62c311478 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -773,7 +773,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tdie(_(\"the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.\"));\n \n \t\tcreate_branch(argv[0], (argc == 2) ? argv[1] : head,\n-\t\t\t force, reflog, 0, quiet, track);\n+\t\t\t force, 0, reflog, quiet, track);\n \n \t} else\n \t\tusage_with_options(builtin_branch_usage, options);\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 5c202b7af..4ef7a47e1 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -641,8 +641,8 @@ static void update_refs_for_switch(const struct checkout_opts *opts,\n \t\telse\n \t\t\tcreate_branch(opts->new_branch, new->name,\n \t\t\t\t opts->new_branch_force ? 1 : 0,\n-\t\t\t\t opts->new_branch_log,\n \t\t\t\t opts->new_branch_force ? 1 : 0,\n+\t\t\t\t opts->new_branch_log,\n \t\t\t\t opts->quiet,\n \t\t\t\t opts->track);\n \t\tnew->name = opts->new_branch;\n-- \n2.14.1.935.ge2b2bcd8a\n\n"},{"id":"328821","messageId":"20170925082024.2691-4-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170925082024.2691-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH v2 3/5] branch: cleanup branch name validation","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-09-25T08:20:22Z","receivedAt":"2017-09-25T08:20:57Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The function that validates a new branch name was clumsy because,\n\n 1. It did more than just validating the branch name.\n\n 2. Despite it's name, it is more often than not used to validate\n existing branch names through the 'force' and 'attr_only'\n parameters (whose names by the way weren't communicative).\n\n 3. The 'attr_only' parameter should have been \"true\" only when\n callers like to update some attribute of the branch and \"false\"\n when they were updating where the branch points to. It was misused\n by callers by setting it to \"true\" (to skip tests) even though they\n were force updating where the current branch was pointing to!\n\n This is an example of spoiling code clarity by making the caller\n rely on how the function is implemented thus making it hard to\n modify/maintain.\n\nThis makes it unclear what the function does at all and would confuse\nthe people who would ever want to it for the first time.\n\nSo, refactor it into a function that validates whether the branch could\nbe created. This doesn't bear the uncommunicative 'new'. Further replace\nthe 'force' parameter with a 'shouldnt_exist' parameter which specifies\nthat a another branch with the given branch name should not (IOW, it's\njust the opposite of 'force') Also replace the 'attr_only' with\n'clobber_head_ok' which is a more communicative way of saying \"If\nanother branch could exist, it's OK if it is the current branch\".\n\nSeparate the validation of an existing branch (partly) into another function.\nThis (at last!) addresses the NEEDSWORK that was added in fa7993767\n(branch --set-upstream: regression fix, 2011-09-16)\n\nThis refactor has only one functional change. It enforces strictly that\nan existing branch should be updated only with the 'force' switch. So,\nit's no more possible to do,\n\n $ git branch -m master master\n\n(which doesn't seem that useful). This strongly enforces the following\nstatement of the 'git branch' documentation,\n\n \"If exists, -M must be used to force the\n rename to happen.\"\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 41 ++++++++++++++++++++++++++++++-----------\n branch.h | 25 +++++++++++++------------\n builtin/branch.c | 2 +-\n builtin/checkout.c | 4 ++--\n t/t3200-branch.sh | 4 ++++\n 5 files changed, 50 insertions(+), 26 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 0ea105b55..db2abeb7e 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -178,18 +178,19 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)\n \treturn 0;\n }\n \n-int validate_new_branchname(const char *name, struct strbuf *ref,\n-\t\t\t int force, int attr_only)\n+int validate_branch_creation(const char *name, struct strbuf *ref,\n+\t\t\t int shouldnt_exist, int clobber_head_ok)\n {\n \tif (strbuf_check_branch_ref(ref, name))\n \t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n \n \tif (!ref_exists(ref->buf))\n \t\treturn 0;\n-\telse if (!force && !attr_only)\n+\n+\tif (shouldnt_exist)\n \t\tdie(_(\"A branch named '%s' already exists.\"), ref->buf + strlen(\"refs/heads/\"));\n \n-\tif (!attr_only) {\n+\tif (!clobber_head_ok) {\n \t\tconst char *head;\n \t\tstruct object_id oid;\n \n@@ -197,9 +198,29 @@ int validate_new_branchname(const char *name, struct strbuf *ref,\n \t\tif (!is_bare_repository() && head && !strcmp(head, ref->buf))\n \t\t\tdie(_(\"Cannot force update the current branch.\"));\n \t}\n+\n \treturn 1;\n }\n \n+/*\n+ * Validates whether the branch with the given name exists, returning the\n+ * interpreted ref in ref.\n+ *\n+ * This method is invoked if the caller merely wants to know if it is OK\n+ * to change some attribute for the named branch (e.g. tracking upstream).\n+ *\n+ */\n+static void validate_existing_branch(const char *name, struct strbuf *ref)\n+{\n+\tif (strbuf_check_branch_ref(ref, name))\n+\t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n+\n+\tif (ref_exists(ref->buf))\n+\t\treturn;\n+\telse\n+\t\tdie(_(\"branch '%s' doesn't exist\"), name);\n+}\n+\n static int check_tracking_branch(struct remote *remote, void *cb_data)\n {\n \tchar *tracking_branch = cb_data;\n@@ -243,13 +264,11 @@ void create_branch(const char *name, const char *start_name,\n \tif (track == BRANCH_TRACK_EXPLICIT || track == BRANCH_TRACK_OVERRIDE)\n \t\texplicit_tracking = 1;\n \n-\tif (validate_new_branchname(name, &ref, force,\n-\t\t\t\t track == BRANCH_TRACK_OVERRIDE ||\n-\t\t\t\t clobber_head_ok)) {\n-\t\tif (!force)\n-\t\t\tdont_change_ref = 1;\n-\t\telse\n-\t\t\tforcing = 1;\n+\tif (track == BRANCH_TRACK_OVERRIDE) {\n+\t\tvalidate_existing_branch(name, &ref);\n+\t\tdont_change_ref = 1;\n+\t} else {\n+\t\tforcing = validate_branch_creation(name, &ref, !force, clobber_head_ok);\n \t}\n \n \treal_ref = NULL;\ndiff --git a/branch.h b/branch.h\nindex a6740bb9f..a6dde552c 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -28,22 +28,23 @@ void create_branch(const char *name, const char *start_name,\n \t\t int reflog, int quiet, enum branch_track track);\n \n /*\n- * Validates that the requested branch may be created, returning the\n- * interpreted ref in ref, force indicates whether (non-head) branches\n- * may be overwritten. A non-zero return value indicates that the force\n- * parameter was non-zero and the branch already exists.\n+ * Validates whether the branch with the given name may be updated (created, renamed etc.,)\n+ * with respect to the given conditions.\n *\n- * Contrary to all of the above, when attr_only is 1, the caller is\n- * not interested in verifying if it is Ok to update the named\n- * branch to point at a potentially different commit. It is merely\n- * asking if it is OK to change some attribute for the named branch\n- * (e.g. tracking upstream).\n+ * - name is the new branch name\n *\n- * NEEDSWORK: This needs to be split into two separate functions in the\n- * longer run for sanity.\n+ * - ref contains the interpreted ref for the given name\n+ *\n+ * - shouldnt_exist indicates that another branch with the given name\n+ * should not exist\n+ *\n+ * - clobber_head_ok allows another branch with given branch name to be\n+ * the currently checkout branch; with 'shouldnt_exist', it has no effect.\n+ *\n+ * A non-zero return value indicates that a branch already exists and can be force updated.\n *\n */\n-int validate_new_branchname(const char *name, struct strbuf *ref, int force, int attr_only);\n+int validate_branch_creation(const char *name, struct strbuf *ref, int shouldnt_exist, int clobber_head_ok);\n \n /*\n * Remove information about the state of working on the current\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 62c311478..aa2f36519 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -483,7 +483,7 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t */\n \tclobber_head_ok = !strcmp(oldname, newname);\n \n-\tvalidate_new_branchname(newname, &newref, force, clobber_head_ok);\n+\tvalidate_branch_creation(newname, &newref, !force, clobber_head_ok);\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 4ef7a47e1..fcbbbb1fa 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1283,8 +1283,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\tstruct strbuf buf = STRBUF_INIT;\n \n \t\topts.branch_exists =\n-\t\t\tvalidate_new_branchname(opts.new_branch, &buf,\n-\t\t\t\t\t\t!!opts.new_branch_force,\n+\t\t\tvalidate_branch_creation(opts.new_branch, &buf,\n+\t\t\t\t\t\t!opts.new_branch_force,\n \t\t\t\t\t\t!!opts.new_branch_force);\n \n \t\tstrbuf_release(&buf);\ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex d97164997..ec85cd959 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -137,6 +137,10 @@ test_expect_success 'git branch -m -f o/q o/p should work when o/p exists' '\n \tgit branch -m -f o/q o/p\n '\n \n+test_expect_success 'git branch -m o/o o/o should fail when o/o exists' '\n+\ttest_must_fail git branch -m o/o o/o\n+'\n+\n test_expect_success 'git branch -m q r/q should fail when r exists' '\n \tgit branch q &&\n \tgit branch r &&\n-- \n2.14.1.935.ge2b2bcd8a\n\n"},{"id":"328822","messageId":"20170925082024.2691-5-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170925082024.2691-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH v2 4/5] branch: introduce dont_fail parameter for create validation","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-09-25T08:20:23Z","receivedAt":"2017-09-25T08:21:04Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"This parameter allows the branch create validation function to\noptionally return a flag specifying the reason for failure, when\nrequested. This allows the caller to know why it was about to die.\nThis allows more useful error messages to be given to the user when\ntrying to rename a branch.\n\nThe flags are specified in the form of an enum and values for success\nflags have been assigned explicitly to clearly express that certain\ncallers rely those values and they cannot be arbitrary.\n\nOnly the logic has been added but no caller has been made to use it, yet.\nSo, no functional changes.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 32 ++++++++++++++++++++++----------\n branch.h | 23 +++++++++++++++++++++--\n builtin/branch.c | 2 +-\n builtin/checkout.c | 2 +-\n 4 files changed, 45 insertions(+), 14 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex db2abeb7e..83305ded6 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -179,27 +179,39 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)\n }\n \n int validate_branch_creation(const char *name, struct strbuf *ref,\n-\t\t\t int shouldnt_exist, int clobber_head_ok)\n+\t\t\t int shouldnt_exist, int clobber_head_ok, unsigned dont_fail)\n {\n-\tif (strbuf_check_branch_ref(ref, name))\n-\t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n+\tif (strbuf_check_branch_ref(ref, name)) {\n+\t\tif (dont_fail)\n+\t\t\treturn INVALID_BRANCH_NAME;\n+\t\telse\n+\t\t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n+\t}\n \n \tif (!ref_exists(ref->buf))\n-\t\treturn 0;\n+\t\treturn VALID_BRANCH_NAME;\n \n-\tif (shouldnt_exist)\n-\t\tdie(_(\"A branch named '%s' already exists.\"), ref->buf + strlen(\"refs/heads/\"));\n+\tif (shouldnt_exist) {\n+\t\tif (dont_fail)\n+\t\t\treturn BRANCH_EXISTS;\n+\t\telse\n+\t\t\tdie(_(\"A branch named '%s' already exists.\"), ref->buf + strlen(\"refs/heads/\"));\n+\t}\n \n \tif (!clobber_head_ok) {\n \t\tconst char *head;\n \t\tstruct object_id oid;\n \n \t\thead = resolve_ref_unsafe(\"HEAD\", 0, oid.hash, NULL);\n-\t\tif (!is_bare_repository() && head && !strcmp(head, ref->buf))\n-\t\t\tdie(_(\"Cannot force update the current branch.\"));\n+\t\tif (!is_bare_repository() && head && !strcmp(head, ref->buf)) {\n+\t\t\tif (dont_fail)\n+\t\t\t\treturn CANNOT_FORCE_UPDATE_CURRENT_BRANCH;\n+\t\t\telse\n+\t\t\t\tdie(_(\"Cannot force update the current branch.\"));\n+\t\t}\n \t}\n \n-\treturn 1;\n+\treturn FORCE_UPDATING_BRANCH;\n }\n \n /*\n@@ -268,7 +280,7 @@ void create_branch(const char *name, const char *start_name,\n \t\tvalidate_existing_branch(name, &ref);\n \t\tdont_change_ref = 1;\n \t} else {\n-\t\tforcing = validate_branch_creation(name, &ref, !force, clobber_head_ok);\n+\t\tforcing = validate_branch_creation(name, &ref, !force, clobber_head_ok, 0);\n \t}\n \n \treal_ref = NULL;\ndiff --git a/branch.h b/branch.h\nindex a6dde552c..4b68a789d 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -27,6 +27,16 @@ void create_branch(const char *name, const char *start_name,\n \t\t int force, int clobber_head_ok,\n \t\t int reflog, int quiet, enum branch_track track);\n \n+enum branch_validation_result {\n+\t/* Flags that say it's NOT OK to update */\n+\tBRANCH_EXISTS = -3,\n+\tCANNOT_FORCE_UPDATE_CURRENT_BRANCH,\n+\tINVALID_BRANCH_NAME,\n+\t/* Flags that say it's OK to update */\n+\tVALID_BRANCH_NAME = 0,\n+\tFORCE_UPDATING_BRANCH = 1\n+};\n+\n /*\n * Validates whether the branch with the given name may be updated (created, renamed etc.,)\n * with respect to the given conditions.\n@@ -41,10 +51,19 @@ void create_branch(const char *name, const char *start_name,\n * - clobber_head_ok allows another branch with given branch name to be\n * the currently checkout branch; with 'shouldnt_exist', it has no effect.\n *\n- * A non-zero return value indicates that a branch already exists and can be force updated.\n+ * The return values have the following meaning,\n+ *\n+ * - If dont_fail is 0, the function dies in case of failure and returns flags of\n+ * 'validate_result' that indicate that it's OK to update the branch. The positive\n+ * non-zero flag implies that the branch can be force updated.\n+ *\n+ * - If dont_fail is 1, the function doesn't die in case of failure but returns flags\n+ * of 'validate_result' that specify the reason for failure. The behaviour in case of\n+ * success is same as above.\n *\n */\n-int validate_branch_creation(const char *name, struct strbuf *ref, int shouldnt_exist, int clobber_head_ok);\n+int validate_branch_creation(const char *name, struct strbuf *ref,\n+\t\t\t int shouldnt_exist, int clobber_head_ok, unsigned dont_fail);\n \n /*\n * Remove information about the state of working on the current\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex aa2f36519..25e3a2f29 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -483,7 +483,7 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t */\n \tclobber_head_ok = !strcmp(oldname, newname);\n \n-\tvalidate_branch_creation(newname, &newref, !force, clobber_head_ok);\n+\tvalidate_branch_creation(newname, &newref, !force, clobber_head_ok, 0);\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex fcbbbb1fa..e9d636c66 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1285,7 +1285,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\topts.branch_exists =\n \t\t\tvalidate_branch_creation(opts.new_branch, &buf,\n \t\t\t\t\t\t!opts.new_branch_force,\n-\t\t\t\t\t\t!!opts.new_branch_force);\n+\t\t\t\t\t\t!!opts.new_branch_force, 0);\n \n \t\tstrbuf_release(&buf);\n \t}\n-- \n2.14.1.935.ge2b2bcd8a\n\n"},{"id":"328823","messageId":"20170925082024.2691-6-kaarticsivaraam91196@gmail.com","threadId":"46452","inReplyTo":"20170925082024.2691-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH v2 5/5] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-09-25T08:20:24Z","receivedAt":"2017-09-25T08:21:08Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"When trying to rename an inexistent branch to with a name of a branch\nthat already exists the rename failed specifying the new branch name\nexists rather than specifying that the branch trying to be renamed\ndoesn't exist.\n\n $ git branch -m tset master\n fatal: A branch named 'master' already exists.\n\nIt's conventional to report that 'tset' doesn't exist rather than\nreporting that 'master' exists, the same way the 'mv' command does.\n\n (hypothetical)\n $ git branch -m tset master\n fatal: branch 'tset' doesn't exist.\n\nThat has the problem that the error about an existing branch is shown\nonly after the user corrects the error about inexistent branch.\n\n $ git branch -m test master\n fatal: A branch named 'master' already exists.\n\nThis isn't useful either because the user would have corrected this error in\na single go if he had been told this alongside the first error. So, give\nmore useful error messages by giving errors about old branch name and new\nbranch name at the same time. This is possible as the branch validation\nfunction now returns the reason it was about to die, when requested.\n\n $ git branch -m tset master\n fatal: branch 'tset' doesn't exist, and branch 'master' already exists\n\nNote: Thanks to the strbuf API that made it possible to easily construct\nthe composite error message strings!\n\nSigned-off-by: Kaartic Sivaraam \n---\n builtin/branch.c | 41 +++++++++++++++++++++++++++++++++++------\n 1 file changed, 35 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 25e3a2f29..0c2017bee 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -456,25 +456,49 @@ static void reject_rebase_or_bisect_branch(const char *target)\n \tfree_worktrees(worktrees);\n }\n \n+static void get_error_msg(struct strbuf* error_msg, const char* oldname, unsigned old_branch_exists,\n+\t\t\t const char* newname, int new_branch_validation_result)\n+{\n+\tconst char* connector_string = _(\", and \");\n+\n+\tif (!old_branch_exists) {\n+\t\tstrbuf_addf(error_msg, _(\"branch '%s' doesn't exist\"), oldname);\n+\t}\n+\n+\tswitch (new_branch_validation_result) {\n+\t\tcase BRANCH_EXISTS:\n+\t\t\tstrbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n+\t\t\tstrbuf_addf(error_msg,_(\"branch '%s' already exists\"), newname);\n+\t\t\tbreak;\n+\t\tcase CANNOT_FORCE_UPDATE_CURRENT_BRANCH:\n+\t\t\tstrbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n+\t\t\tstrbuf_addstr(error_msg, _(\"cannot force update the current branch\"));\n+\t\t\tbreak;\n+\t\tcase INVALID_BRANCH_NAME:\n+\t\t\tstrbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n+\t\t\tstrbuf_addf(error_msg, _(\"branch name '%s' is invalid\"), newname);\n+\t\t\tbreak;\n+\t}\n+}\n+\n static void rename_branch(const char *oldname, const char *newname, int force)\n {\n \tstruct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n \tstruct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n \tint recovery = 0;\n \tint clobber_head_ok;\n+\tstruct strbuf error_msg = STRBUF_INIT, empty = STRBUF_INIT;\n \n \tif (!oldname)\n \t\tdie(_(\"cannot rename the current branch while not on any.\"));\n \n-\tif (strbuf_check_branch_ref(&oldref, oldname)) {\n+\tif (strbuf_check_branch_ref(&oldref, oldname) && ref_exists(oldref.buf))\n+\t{\n \t\t/*\n \t\t * Bad name --- this could be an attempt to rename a\n \t\t * ref that we used to allow to be created by accident.\n \t\t */\n-\t\tif (ref_exists(oldref.buf))\n-\t\t\trecovery = 1;\n-\t\telse\n-\t\t\tdie(_(\"Invalid branch name: '%s'\"), oldname);\n+\t\trecovery = 1;\n \t}\n \n \t/*\n@@ -483,7 +507,10 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t */\n \tclobber_head_ok = !strcmp(oldname, newname);\n \n-\tvalidate_branch_creation(newname, &newref, !force, clobber_head_ok, 0);\n+\tget_error_msg(&error_msg, oldname, ref_exists(oldref.buf),\n+\t\t\tnewname, validate_branch_creation(newname, &newref, !force, clobber_head_ok, 1));\n+\tif (strbuf_cmp(&error_msg, &empty))\n+\t\tdie(\"%s\", error_msg.buf);\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \n@@ -509,6 +536,8 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t\tdie(_(\"Branch is renamed, but update of config-file failed\"));\n \tstrbuf_release(&oldsection);\n \tstrbuf_release(&newsection);\n+\tstrbuf_release(&error_msg);\n+\tstrbuf_release(&empty);\n }\n \n static GIT_PATH_FUNC(edit_description, \"EDIT_DESCRIPTION\")\n-- \n2.14.1.935.ge2b2bcd8a\n\n"},{"id":"330718","messageId":"1508483371.2601.8.camel@gmail.com","threadId":"46452","inReplyTo":"20170925082024.2691-1-kaarticsivaraam91196@gmail.com","subject":"Re: [RFC PATCH v2 0/5] Give more useful error messages when renaming a branch","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-10-20T07:09:31Z","receivedAt":"2017-10-20T07:09:50Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"What happened to the v2 of the patch? Has this not received attention\nor is there anything that's not done correctly?\n\n-- \nKaartic\n"},{"id":"330738","messageId":"CAGZ79kb9iSzYkmET8Xp=Hz-x+q_rdsaS1F7A3p1Q+URZ3uRCcw@mail.gmail.com","threadId":"46452","inReplyTo":"1508483371.2601.8.camel@gmail.com","subject":"Re: [RFC PATCH v2 0/5] Give more useful error messages when renaming a branch","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-10-20T18:58:17Z","receivedAt":"2017-10-20T18:58:23Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Oct 20, 2017 at 12:09 AM, Kaartic Sivaraam\n wrote:\n> What happened to the v2 of the patch? Has this not received attention\n> or is there anything that's not done correctly?\n>\n\nI just checked origin/pu as well as the latest cooking email\nhttps://public-inbox.org/git/xmqqr2tzith7.fsf@gitster.mtv.corp.google.com/\nand could not find your series.\n\nSorry for dropping the ball as a reviewer, I'll take a look.\n\nThanks for pinging,\nStefan\n"},{"id":"330744","messageId":"CAGZ79kaVUBuHVxaE0opXqiEwCr7MVFZHrt5ERQ0mF_deSHeOSQ@mail.gmail.com","threadId":"46452","inReplyTo":"20170925082024.2691-2-kaarticsivaraam91196@gmail.com","subject":"Re: [RFC PATCH v2 1/5] branch: improve documentation and naming of certain parameters","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-10-20T21:33:42Z","receivedAt":"2017-10-20T21:33:48Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Sep 25, 2017 at 1:20 AM, Kaartic Sivaraam\n wrote:\n> Documentation for a certain function was incomplete as it didn't say\n> what certain parameters were used for. Further a parameter name wasn't\n> very communicative.\n>\n> So, add missing documentation for the sake of completeness and easy\n> reference. Also, rename the concerned parameter to make it's name more\n> communicative.\n>\n> Signed-off-by: Kaartic Sivaraam \n\nUp to here ( including the subject line), I have no idea you're talking about\n'create_branch'. Maybe\n\n branch: improve documentation and naming of parameters for create_branch\n\n The documentation for 'create_branch' was incomplete ...\n\nThe patch itself looks great!\n\nThanks,\nStefan\n"},{"id":"330747","messageId":"CAGZ79kYLX+mXaWA-ZGnCWE7UBoZ2N76_MHQ6tB7+yGYDBRXUCA@mail.gmail.com","threadId":"46452","inReplyTo":"20170925082024.2691-3-kaarticsivaraam91196@gmail.com","subject":"Re: [RFC PATCH v2 2/5] branch: re-order function arguments to group related arguments","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-10-20T21:50:15Z","receivedAt":"2017-10-20T21:50:21Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Sep 25, 2017 at 1:20 AM, Kaartic Sivaraam\n wrote:\n> The ad-hoc patches to add new arguments to a function when needed\n> resulted in the related arguments not being close to each other.\n> This misleads the person reading the code to believe that there isn't\n> much relation between those arguments while it's not the case.\n>\n> So, re-order the arguments to keep the related arguments close to each\n> other.\n\nThanks for taking a lot at the code quality in detail.\n\nIn my currently checked out version of Git, there are two occurrences\nof create_branch in builtin/branch.c, this patch converts only one occurrence.\n\n(So you'd need to convert that second one, too. Oh wait; it is converted\nimplicitly as the arguments are both '0':\n create_branch(branch->name, new_upstream, 0, 0, 0, \\\n quiet, BRANCH_TRACK_OVERRIDE);\n)\n\nThis leads to the generic problem of this patch: Assume there are other\ncontributors that write patches. They may introduce new calls to\n`create_branch`, but using the order of parameters as they may\nbe unaware of this patch and they'd test without this patch.\n\nAs the signature of the function call doesn't change the compiler\ndoesn't assist us in finding such a potential race between patches.\n\nI am not aware of any other patches in flight, so we *might* be fine\nwith this patch. But hope is rarely a good strategy.\n\nCan we change the function signature (the name or another order\nof arguments that also makes sense, or making one of the\nparameters an enum) such that a potential race can be detected\neasier?\n\nThanks,\nStefan\n"},{"id":"330748","messageId":"CAPig+cS7e2i-eEJV6NcRQ-+aVmn5C7mKONxU4TLAGA7GQBX=aw@mail.gmail.com","threadId":"46452","inReplyTo":"CAGZ79kaVUBuHVxaE0opXqiEwCr7MVFZHrt5ERQ0mF_deSHeOSQ@mail.gmail.com","subject":"Re: [RFC PATCH v2 1/5] branch: improve documentation and naming of certain parameters","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2017-10-20T21:51:49Z","receivedAt":"2017-10-20T21:51:55Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Sep 25, 2017 at 1:20 AM, Kaartic Sivaraam\n wrote:\n> Documentation for a certain function was incomplete as it didn't say\n> what certain parameters were used for. Further a parameter name wasn't\n> very communicative.\n>\n> So, add missing documentation for the sake of completeness and easy\n> reference. Also, rename the concerned parameter to make it's name more\n\ns/it's/its/\n\n> communicative.\n>\n> Signed-off-by: Kaartic Sivaraam \n"},{"id":"330764","messageId":"1508553102.2516.2.camel@gmail.com","threadId":"46452","inReplyTo":"CAGZ79kaVUBuHVxaE0opXqiEwCr7MVFZHrt5ERQ0mF_deSHeOSQ@mail.gmail.com","subject":"Re: [RFC PATCH v2 1/5] branch: improve documentation and naming of certain parameters","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-10-21T02:31:42Z","receivedAt":"2017-10-21T02:31:53Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Fri, 2017-10-20 at 14:33 -0700, Stefan Beller wrote:\n> Up to here ( including the subject line), I have no idea you're talking about\n> 'create_branch'. Maybe\n> \n\nThat's because I didn't want to be explicit.\n\n> branch: improve documentation and naming of parameters for create_branch\n> \n> The documentation for 'create_branch' was incomplete ...\n> \n\nSounds good, will use it.\n\n-- \nKaartic\n"},{"id":"330765","messageId":"1508553136.2516.4.camel@gmail.com","threadId":"46452","inReplyTo":"CAPig+cS7e2i-eEJV6NcRQ-+aVmn5C7mKONxU4TLAGA7GQBX=aw@mail.gmail.com","subject":"Re: [RFC PATCH v2 1/5] branch: improve documentation and naming of certain parameters","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-10-21T02:32:16Z","receivedAt":"2017-10-21T02:32:27Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Fri, 2017-10-20 at 17:51 -0400, Eric Sunshine wrote:\n> On Mon, Sep 25, 2017 at 1:20 AM, Kaartic Sivaraam\n> wrote:\n> > Documentation for a certain function was incomplete as it didn't say\n> > what certain parameters were used for. Further a parameter name wasn't\n> > very communicative.\n> > \n> > So, add missing documentation for the sake of completeness and easy\n> > reference. Also, rename the concerned parameter to make it's name more\n> \n> s/it's/its/\n> \n\nThanks!\n\n-- \nKaartic\n"},{"id":"330768","messageId":"1508554594.2516.7.camel@gmail.com","threadId":"46452","inReplyTo":"CAGZ79kYLX+mXaWA-ZGnCWE7UBoZ2N76_MHQ6tB7+yGYDBRXUCA@mail.gmail.com","subject":"Re: [RFC PATCH v2 2/5] branch: re-order function arguments to group related arguments","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-10-21T02:56:34Z","receivedAt":"2017-10-21T02:56:46Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Fri, 2017-10-20 at 14:50 -0700, Stefan Beller wrote:\n> On Mon, Sep 25, 2017 at 1:20 AM, Kaartic Sivaraam\n> wrote:\n> > The ad-hoc patches to add new arguments to a function when needed\n> > resulted in the related arguments not being close to each other.\n> > This misleads the person reading the code to believe that there isn't\n> > much relation between those arguments while it's not the case.\n> > \n> > So, re-order the arguments to keep the related arguments close to each\n> > other.\n> \n> Thanks for taking a lot at the code quality in detail.\n> \n> In my currently checked out version of Git, there are two occurrences\n> of create_branch in builtin/branch.c, this patch converts only one occurrence.\n> \n> (So you'd need to convert that second one, too. Oh wait; it is converted\n> implicitly as the arguments are both '0':\n> create_branch(branch->name, new_upstream, 0, 0, 0, \\\n> quiet, BRANCH_TRACK_OVERRIDE);\n> )\n> \n> This leads to the generic problem of this patch: Assume there are other\n> contributors that write patches. They may introduce new calls to\n> `create_branch`, but using the order of parameters as they may\n> be unaware of this patch and they'd test without this patch.\n> \n> As the signature of the function call doesn't change the compiler\n> doesn't assist us in finding such a potential race between patches.\n> \n> I am not aware of any other patches in flight, so we *might* be fine\n> with this patch. But hope is rarely a good strategy.\n> \n> Can we change the function signature (the name or another order\n> of arguments that also makes sense, or making one of the\n> parameters an enum) such that a potential race can be detected\n> easier?\n> \n\nI don't have a great interest in keeping this patch in case it might\nconflict with other patches. Anyways, I guess we could avoid the issue\nby making the last 'enum' parameter as the third parameter. It pretty\nwell changes the order by moving the flag-like parameters to the last\nbut it doesn't change the signature very strongly as you can pass\nintegers in the place of enums. (I guess that also obviates the\nsuggestion of making one parameter an enum)\n\nSo, the only way around is to rename the function which is something I\nwouldn't like to do myself unless other people like the idea. So,\nshould I drop this patch or should I rename the function?\n\n\n-- \nKaartic\n"},{"id":"330848","messageId":"CAGZ79kbmqfW+Z1hWUhiOPKQzd0_bDzZrkKrFt=YbvCcKCfd7YA@mail.gmail.com","threadId":"46452","inReplyTo":"1508554594.2516.7.camel@gmail.com","subject":"Re: [RFC PATCH v2 2/5] branch: re-order function arguments to group related arguments","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-10-23T19:32:53Z","receivedAt":"2017-10-23T19:33:01Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Oct 20, 2017 at 7:56 PM, Kaartic Sivaraam\n wrote:\n> On Fri, 2017-10-20 at 14:50 -0700, Stefan Beller wrote:\n>> On Mon, Sep 25, 2017 at 1:20 AM, Kaartic Sivaraam\n>> wrote:\n>> > The ad-hoc patches to add new arguments to a function when needed\n>> > resulted in the related arguments not being close to each other.\n>> > This misleads the person reading the code to believe that there isn't\n>> > much relation between those arguments while it's not the case.\n>> >\n>> > So, re-order the arguments to keep the related arguments close to each\n>> > other.\n>>\n>> Thanks for taking a lot at the code quality in detail.\n>>\n>> In my currently checked out version of Git, there are two occurrences\n>> of create_branch in builtin/branch.c, this patch converts only one occurrence.\n>>\n>> (So you'd need to convert that second one, too. Oh wait; it is converted\n>> implicitly as the arguments are both '0':\n>> create_branch(branch->name, new_upstream, 0, 0, 0, \\\n>> quiet, BRANCH_TRACK_OVERRIDE);\n>> )\n>>\n>> This leads to the generic problem of this patch: Assume there are other\n>> contributors that write patches. They may introduce new calls to\n>> `create_branch`, but using the order of parameters as they may\n>> be unaware of this patch and they'd test without this patch.\n>>\n>> As the signature of the function call doesn't change the compiler\n>> doesn't assist us in finding such a potential race between patches.\n>>\n>> I am not aware of any other patches in flight, so we *might* be fine\n>> with this patch. But hope is rarely a good strategy.\n>>\n>> Can we change the function signature (the name or another order\n>> of arguments that also makes sense, or making one of the\n>> parameters an enum) such that a potential race can be detected\n>> easier?\n>>\n>\n> I don't have a great interest in keeping this patch in case it might\n> conflict with other patches. Anyways, I guess we could avoid the issue\n> by making the last 'enum' parameter as the third parameter. It pretty\n> well changes the order by moving the flag-like parameters to the last\n> but it doesn't change the signature very strongly as you can pass\n> integers in the place of enums. (I guess that also obviates the\n> suggestion of making one parameter an enum)\n>\n> So, the only way around is to rename the function which is something I\n> wouldn't like to do myself unless other people like the idea. So,\n> should I drop this patch or should I rename the function?\n\nWell let's keep the patch and closely watch next/pu to see if there might\ntopics that conflict, then. I do really like these small fixes to make the\ncode more readable. e.g.\n\n $ git log --oneline origin/master..origin/pu -G create_branch\n"},{"id":"330849","messageId":"CAGZ79kZJAYabHArHkPPyqUy7LKQXyk7kqqmrqRcirGXZ4FYHJQ@mail.gmail.com","threadId":"46452","inReplyTo":"20170925082024.2691-6-kaarticsivaraam91196@gmail.com","subject":"Re: [RFC PATCH v2 5/5] builtin/branch: give more useful error messages when renaming","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-10-23T19:44:01Z","receivedAt":"2017-10-23T19:44:07Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Sep 25, 2017 at 1:20 AM, Kaartic Sivaraam\n wrote:\n> builtin/branch.c | 41 +++++++++++++++++++++++++++++++++++------\n> 1 file changed, 35 insertions(+), 6 deletions(-)\n\nThe code of 4 and 5 looks good to me, though a small nit below.\n\nThanks,\nStefan\n\n\n> +static void get_error_msg(struct strbuf* error_msg, const char* oldname, unsigned old_branch_exists,\n> + const char* newname, int new_branch_validation_result)\n\nnit here and in the return of validate_branch_creation:\nIt would be clearer if this is not just 'int', but actually spelling\nout that it is the enum.\n"},{"id":"330893","messageId":"1508816263.3568.4.camel@gmail.com","threadId":"46452","inReplyTo":"CAGZ79kZJAYabHArHkPPyqUy7LKQXyk7kqqmrqRcirGXZ4FYHJQ@mail.gmail.com","subject":"Re: [RFC PATCH v2 5/5] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-10-24T03:37:43Z","receivedAt":"2017-10-24T03:37:53Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Mon, 2017-10-23 at 12:44 -0700, Stefan Beller wrote:\n> +static void get_error_msg(struct strbuf* error_msg, const char* oldname, unsigned old_branch_exists,\n> > + const char* newname, int new_branch_validation_result)\n> \n> nit here and in the return of validate_branch_creation:\n> It would be clearer if this is not just 'int', but actually spelling\n> out that it is the enum.\n\nThanks. That's a good suggestion. I'll fix it while dropping [PATCH\n3/5] that cleans up the 'validate_new_branchname' function as there's\nalready another series that refactored the same function and got merged\nto 'next',\n\nhttps://public-inbox.org/git/20171013051132.3973-1-gitster@pobox.com/\n\n\n-- \nKaartic\n"},{"id":"331652","messageId":"20171102065407.25404-1-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20170925082024.2691-1-kaarticsivaraam91196@gmail.com","subject":"[RFC PATCH v3 0/4] give more useful error messages while renaming branch","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-02T06:54:03Z","receivedAt":"2017-11-02T06:54:22Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"In builtin/branch, the error messages weren't handled directly by the branch\nrenaming function and was left to the other function. Though this avoids\nredundancy this gave unclear error messages in some cases. So, make builtin/branch\ngive more useful error messages.\n\nChanges in v3:\n\n\tIncorporated suggestions from v2 to improve code and commit message. To\n\tbe more precise about the code part,\n\n\tIn 2/4 slightly re-ordered the parameters to move the flag parameters to\n\tthe end.\n\n\tIn 3/4, changed the return type of the branchname validation functions to\n\tbe the enum (whose values they return) as suggested by Stefan.\n\n\tDropped the PATCH 3/5 of v2 as there was another series[1] that did the\n\trefactor and got merged to 'next'. I have now re-rolled the series over\n\t'next' [pointing at 273055501 (Sync with master, 2017-10-24)].\n \n\tThis has made the code in 3/4 a little clumsy (at least to me) as I\n\ttried to achieve to achieve what the previous patches did with the new\n\tvalidate*_branchname functionS. Let me know, if it looks too bad.\n\nSo this could go on top of 'next' without any conflicts but in case I\nmissed something, let me know. The series could be found in my fork[2].\n\n\nAny feedback welcome.\n\nThanks,\nKaartic\n\n[1] : https://public-inbox.org/git/20171013051132.3973-1-gitster@pobox.com\n\n[2] : https://github.com/sivaraam/git/tree/work/branch-revamp\n\n\nKaartic Sivaraam (4):\n branch: improve documentation and naming of 'create_branch()'\n branch: re-order function arguments to group related arguments\n branch: introduce dont_fail parameter for branchname validation\n builtin/branch: give more useful error messages when renaming\n\n branch.c | 63 ++++++++++++++++++++++++++++++------------------------\n branch.h | 57 ++++++++++++++++++++++++++++++++++++++----------\n builtin/branch.c | 49 ++++++++++++++++++++++++++++++++++--------\n builtin/checkout.c | 11 +++++-----\n 4 files changed, 127 insertions(+), 53 deletions(-)\n\n-- \n2.15.0.rc2.401.g3db9995f9\n"},{"id":"331653","messageId":"20171102065407.25404-3-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171102065407.25404-1-kaartic.sivaraam@gmail.com","subject":"[RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-02T06:54:05Z","receivedAt":"2017-11-02T06:54:32Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"From: Kaartic Sivaraam \n\nThe ad-hoc patches to add new arguments to a function when needed\nresulted in the related arguments not being close to each other.\nThis misleads the person reading the code to believe that there isn't\nmuch relation between those arguments while it's not the case.\n\nSo, re-order the arguments to keep the related arguments close to each\nother.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 4 ++--\n branch.h | 14 +++++++-------\n builtin/branch.c | 4 ++--\n builtin/checkout.c | 6 +++---\n 4 files changed, 14 insertions(+), 14 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex ea6e2b359..7c8093041 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -244,8 +244,8 @@ N_(\"\\n\"\n \"\\\"git push -u\\\" to set the upstream config as you push.\");\n \n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog, int clobber_head_ok,\n-\t\t int quiet, enum branch_track track)\n+\t\t enum branch_track track, int force, int clobber_head_ok,\n+\t\t int reflog, int quiet)\n {\n \tstruct commit *commit;\n \tstruct object_id oid;\ndiff --git a/branch.h b/branch.h\nindex 1512b78d1..85052628b 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -11,21 +11,21 @@\n * - start_name is the name of the existing branch that the new branch should\n * start from\n *\n- * - force enables overwriting an existing (non-head) branch\n+ * - track causes the new branch to be configured to merge the remote branch\n+ * that start_name is a tracking branch for (if any).\n *\n- * - reflog creates a reflog for the branch\n+ * - force enables overwriting an existing (non-head) branch\n *\n * - clobber_head_ok allows the currently checked out (hence existing)\n * branch to be overwritten; without 'force', it has no effect.\n *\n- * - quiet suppresses tracking information\n+ * - reflog creates a reflog for the branch\n *\n- * - track causes the new branch to be configured to merge the remote branch\n- * that start_name is a tracking branch for (if any).\n+ * - quiet suppresses tracking information\n */\n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog,\n-\t\t int clobber_head_ok, int quiet, enum branch_track track);\n+\t\t enum branch_track track, int force, int clobber_head_ok,\n+\t\t int reflog, int quiet);\n \n /*\n * Check if 'name' can be a valid name for a branch; die otherwise.\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 5be40b384..df06ac968 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -766,7 +766,7 @@ 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\t */\n-\t\tcreate_branch(branch->name, new_upstream, 0, 0, 0, quiet, BRANCH_TRACK_OVERRIDE);\n+\t\tcreate_branch(branch->name, new_upstream, BRANCH_TRACK_OVERRIDE, 0, 0, 0, quiet);\n \t} else if (unset_upstream) {\n \t\tstruct branch *branch = branch_get(argv[0]);\n \t\tstruct strbuf buf = STRBUF_INIT;\n@@ -806,7 +806,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tdie(_(\"the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.\"));\n \n \t\tcreate_branch(argv[0], (argc == 2) ? argv[1] : head,\n-\t\t\t force, reflog, 0, quiet, track);\n+\t\t\t track, force, 0, reflog, quiet);\n \n \t} else\n \t\tusage_with_options(builtin_branch_usage, options);\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 8546d630b..5c34a9a0d 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -639,11 +639,11 @@ static void update_refs_for_switch(const struct checkout_opts *opts,\n \t\t}\n \t\telse\n \t\t\tcreate_branch(opts->new_branch, new->name,\n+\t\t\t\t opts->track,\n+\t\t\t\t opts->new_branch_force ? 1 : 0,\n \t\t\t\t opts->new_branch_force ? 1 : 0,\n \t\t\t\t opts->new_branch_log,\n-\t\t\t\t opts->new_branch_force ? 1 : 0,\n-\t\t\t\t opts->quiet,\n-\t\t\t\t opts->track);\n+\t\t\t\t opts->quiet);\n \t\tnew->name = opts->new_branch;\n \t\tsetup_branch_path(new);\n \t}\n-- \n2.15.0.461.gf957c703b.dirty\n\n"},{"id":"331654","messageId":"20171102065407.25404-4-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171102065407.25404-1-kaartic.sivaraam@gmail.com","subject":"[RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-02T06:54:06Z","receivedAt":"2017-11-02T06:54:34Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"This parameter allows the branchname validation functions to\noptionally return a flag specifying the reason for failure, when\nrequested. This allows the caller to know why it was about to die.\nThis allows more useful error messages to be given to the user when\ntrying to rename a branch.\n\nThe flags are specified in the form of an enum and values for success\nflags have been assigned explicitly to clearly express that certain\ncallers rely on those values and they cannot be arbitrary.\n\nOnly the logic has been added but no caller has been made to use it, yet.\nSo, no functional changes.\n\nSigned-off-by: Kaartic Sivaraam \nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 62 +++++++++++++++++++++++++++++++-----------------------\n branch.h | 60 ++++++++++++++++++++++++++++++++++++++++++----------\n builtin/branch.c | 4 ++--\n builtin/checkout.c | 5 +++--\n 4 files changed, 90 insertions(+), 41 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 7c8093041..7db2e3296 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -178,41 +178,51 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)\n \treturn 0;\n }\n \n-/*\n- * Check if 'name' can be a valid name for a branch; die otherwise.\n- * Return 1 if the named branch already exists; return 0 otherwise.\n- * Fill ref with the full refname for the branch.\n- */\n-int validate_branchname(const char *name, struct strbuf *ref)\n+enum branch_validation_result validate_branchname(const char *name, struct strbuf *ref, unsigned dont_fail)\n {\n-\tif (strbuf_check_branch_ref(ref, name))\n-\t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n+\tif (strbuf_check_branch_ref(ref, name)) {\n+\t\tif (dont_fail)\n+\t\t\treturn INVALID_BRANCH_NAME;\n+\t\telse\n+\t\t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n+\t}\n \n-\treturn ref_exists(ref->buf);\n+\tif(ref_exists(ref->buf))\n+\t\treturn BRANCH_EXISTS;\n+\telse\n+\t\treturn BRANCH_DOESNT_EXIST;\n }\n \n-/*\n- * Check if a branch 'name' can be created as a new branch; die otherwise.\n- * 'force' can be used when it is OK for the named branch already exists.\n- * Return 1 if the named branch already exists; return 0 otherwise.\n- * Fill ref with the full refname for the branch.\n- */\n-int validate_new_branchname(const char *name, struct strbuf *ref, int force)\n+enum branch_validation_result validate_new_branchname(const char *name, struct strbuf *ref, int force, unsigned dont_fail)\n {\n \tconst char *head;\n \n-\tif (!validate_branchname(name, ref))\n-\t\treturn 0;\n+\tif(dont_fail) {\n+\t\tenum branch_validation_result res = validate_branchname(name, ref, 1);\n+\t\tif (res == INVALID_BRANCH_NAME || res == BRANCH_DOESNT_EXIST)\n+\t\t\t\treturn res;\n+\t} else {\n+\t\tif(validate_branchname(name, ref, 0) == BRANCH_DOESNT_EXIST)\n+\t\t\treturn BRANCH_DOESNT_EXIST;\n+\t}\n \n-\tif (!force)\n-\t\tdie(_(\"A branch named '%s' already exists.\"),\n-\t\t ref->buf + strlen(\"refs/heads/\"));\n+\tif (!force) {\n+\t\tif (dont_fail)\n+\t\t\treturn BRANCH_EXISTS_NO_FORCE;\n+\t\telse\n+\t\t\tdie(_(\"A branch named '%s' already exists.\"),\n+\t\t\t\tref->buf + strlen(\"refs/heads/\"));\n+\t}\n \n \thead = resolve_ref_unsafe(\"HEAD\", 0, NULL, NULL);\n-\tif (!is_bare_repository() && head && !strcmp(head, ref->buf))\n-\t\tdie(_(\"Cannot force update the current branch.\"));\n+\tif (!is_bare_repository() && head && !strcmp(head, ref->buf)) {\n+\t\tif (dont_fail)\n+\t\t\treturn CANNOT_FORCE_UPDATE_CURRENT_BRANCH;\n+\t\telse\n+\t\t\tdie(_(\"Cannot force update the current branch.\"));\n+\t}\n \n-\treturn 1;\n+\treturn BRANCH_EXISTS;\n }\n \n static int check_tracking_branch(struct remote *remote, void *cb_data)\n@@ -259,8 +269,8 @@ void create_branch(const char *name, const char *start_name,\n \t\texplicit_tracking = 1;\n \n \tif ((track == BRANCH_TRACK_OVERRIDE || clobber_head_ok)\n-\t ? validate_branchname(name, &ref)\n-\t : validate_new_branchname(name, &ref, force)) {\n+\t ? validate_branchname(name, &ref, 0)\n+\t : validate_new_branchname(name, &ref, force, 0)) {\n \t\tif (!force)\n \t\t\tdont_change_ref = 1;\n \t\telse\ndiff --git a/branch.h b/branch.h\nindex 85052628b..0c178ec5a 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -27,20 +27,58 @@ void create_branch(const char *name, const char *start_name,\n \t\t enum branch_track track, int force, int clobber_head_ok,\n \t\t int reflog, int quiet);\n \n-/*\n- * Check if 'name' can be a valid name for a branch; die otherwise.\n- * Return 1 if the named branch already exists; return 0 otherwise.\n- * Fill ref with the full refname for the branch.\n- */\n-extern int validate_branchname(const char *name, struct strbuf *ref);\n+enum branch_validation_result {\n+\t/* Flags that convey that validation FAILED */\n+\tBRANCH_EXISTS_NO_FORCE = -3,\n+\tCANNOT_FORCE_UPDATE_CURRENT_BRANCH,\n+\tINVALID_BRANCH_NAME,\n+\t/* Flags that convey that validation SUCCEEDED */\n+\tBRANCH_DOESNT_EXIST = 0,\n+\tBRANCH_EXISTS = 1,\n+};\n \n /*\n- * Check if a branch 'name' can be created as a new branch; die otherwise.\n- * 'force' can be used when it is OK for the named branch already exists.\n- * Return 1 if the named branch already exists; return 0 otherwise.\n- * Fill ref with the full refname for the branch.\n+ * Check if 'name' can be a valid name for a branch; die otherwise.\n+ *\n+ * - name is the new branch name\n+ *\n+ * - ref is used to return the full refname for the branch\n+ *\n+ * The return values have the following meaning,\n+ *\n+ * - If dont_fail is 0, the function dies in case of failure and returns flags of\n+ * 'branch_validation_result' that indicate status of the given branch. The positive\n+ * non-zero flag implies that the branch exists.\n+ *\n+ * - If dont_fail is 1, the function doesn't die in case of failure but returns flags\n+ * of 'branch_validaton_result' that specify the reason for failure. The behaviour in case of\n+ * success is same as above.\n+ *\n */\n-extern int validate_new_branchname(const char *name, struct strbuf *ref, int force);\n+extern enum branch_validation_result validate_branchname(const char *name, struct strbuf *ref, unsigned dont_fail);\n+\n+/*\n+ * Check if a branch 'name' can be created as a new branch.\n+ *\n+ * - name is the new branch name\n+ *\n+ * - ref is used to return the full refname for the branch\n+ *\n+ * - force can be used when it is OK if the named branch already exists.\n+ * the currently checkout branch; with 'shouldnt_exist', it has no effect.\n+ *\n+ * The return values have the following meaning,\n+ *\n+ * - If dont_fail is 0, the function dies in case of failure and returns flags of\n+ * 'branch_validation_result' that indicate that convey status of given branch. The positive\n+ * non-zero flag implies that the branch can be force updated.\n+ *\n+ * - If dont_fail is 1, the function doesn't die in case of failure but returns flags\n+ * of 'branch_validaton_result' that specify the reason for failure. The behaviour in case of\n+ * success is same as above.\n+ *\n+ */\n+extern enum branch_validation_result validate_new_branchname(const char *name, struct strbuf *ref, int force, unsigned dont_fail);\n \n /*\n * Remove information about the state of working on the current\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex df06ac968..7018e5d75 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -487,9 +487,9 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \t * cause the worktree to become inconsistent with HEAD, so allow it.\n \t */\n \tif (!strcmp(oldname, newname))\n-\t\tvalidate_branchname(newname, &newref);\n+\t\tvalidate_branchname(newname, &newref, 0);\n \telse\n-\t\tvalidate_new_branchname(newname, &newref, force);\n+\t\tvalidate_new_branchname(newname, &newref, force, 0);\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 5c34a9a0d..4adab3814 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1288,10 +1288,11 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\tstruct strbuf buf = STRBUF_INIT;\n \n \t\tif (opts.new_branch_force)\n-\t\t\topts.branch_exists = validate_branchname(opts.new_branch, &buf);\n+\t\t\topts.branch_exists = validate_branchname(opts.new_branch, &buf, 0);\n \t\telse\n \t\t\topts.branch_exists =\n-\t\t\t\tvalidate_new_branchname(opts.new_branch, &buf, 0);\n+\t\t\t\tvalidate_new_branchname(opts.new_branch, &buf, 0, 0);\n+\n \t\tstrbuf_release(&buf);\n \t}\n \n-- \n2.15.0.461.gf957c703b.dirty\n\n"},{"id":"331655","messageId":"20171102065407.25404-5-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171102065407.25404-1-kaartic.sivaraam@gmail.com","subject":"[RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-02T06:54:07Z","receivedAt":"2017-11-02T06:54:41Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"From: Kaartic Sivaraam \n\nWhen trying to rename an inexistent branch to with a name of a branch\nthat already exists the rename failed specifying the new branch name\nexists rather than specifying that the branch trying to be renamed\ndoesn't exist.\n\n $ git branch -m tset master\n fatal: A branch named 'master' already exists.\n\nIt's conventional to report that 'tset' doesn't exist rather than\nreporting that 'master' exists, the same way the 'mv' command does.\n\n (hypothetical)\n $ git branch -m tset master\n fatal: branch 'tset' doesn't exist.\n\nThat has the problem that the error about an existing branch is shown\nonly after the user corrects the error about inexistent branch.\n\n $ git branch -m test master\n fatal: A branch named 'master' already exists.\n\nThis isn't useful either because the user would have corrected this error in\na single go if he had been told this alongside the first error. So, give\nmore useful error messages by giving errors about old branch name and new\nbranch name at the same time. This is possible as the branch name validation\nfunctions now return the reason they were about to die, when requested.\n\n $ git branch -m tset master\n fatal: branch 'tset' doesn't exist, and branch 'master' already exists\n\nNote: Thanks to the strbuf API that made it possible to easily construct\nthe composite error message strings!\n\nSigned-off-by: Kaartic Sivaraam \n---\n builtin/branch.c | 49 ++++++++++++++++++++++++++++++++++++++++++-------\n 1 file changed, 42 insertions(+), 7 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 7018e5d75..c2bbf8c3d 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -458,11 +458,42 @@ static void reject_rebase_or_bisect_branch(const char *target)\n \tfree_worktrees(worktrees);\n }\n \n+static void get_error_msg(struct strbuf* error_msg, const char* oldname, unsigned old_branch_exists,\n+\t\t\t const char* newname, enum branch_validation_result res)\n+{\n+\tconst char* connector_string = _(\", and \");\n+\n+\tif (!old_branch_exists) {\n+\t\tstrbuf_addf(error_msg, _(\"branch '%s' doesn't exist\"), oldname);\n+\t}\n+\n+\tswitch (res) {\n+\t\tcase BRANCH_EXISTS_NO_FORCE:\n+\t\t\tstrbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n+\t\t\tstrbuf_addf(error_msg,_(\"branch '%s' already exists\"), newname);\n+\t\t\tbreak;\n+\t\tcase CANNOT_FORCE_UPDATE_CURRENT_BRANCH:\n+\t\t\tstrbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n+\t\t\tstrbuf_addstr(error_msg, _(\"cannot force update the current branch\"));\n+\t\t\tbreak;\n+\t\tcase INVALID_BRANCH_NAME:\n+\t\t\tstrbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n+\t\t\tstrbuf_addf(error_msg, _(\"branch name '%s' is invalid\"), newname);\n+\t\t\tbreak;\n+\t\t/* not necessary to handle success cases */\n+\t\tcase BRANCH_EXISTS:\n+\t\tcase BRANCH_DOESNT_EXIST:\n+\t\t\tbreak;\n+\t}\n+}\n+\n static void copy_or_rename_branch(const char *oldname, const char *newname, int copy, int force)\n {\n \tstruct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n \tstruct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n \tint recovery = 0;\n+\tstruct strbuf error_msg = STRBUF_INIT, empty = STRBUF_INIT;\n+\tenum branch_validation_result res;\n \n \tif (!oldname) {\n \t\tif (copy)\n@@ -471,15 +502,13 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \t\t\tdie(_(\"cannot rename the current branch while not on any.\"));\n \t}\n \n-\tif (strbuf_check_branch_ref(&oldref, oldname)) {\n+\tif (strbuf_check_branch_ref(&oldref, oldname) && ref_exists(oldref.buf))\n+\t{\n \t\t/*\n \t\t * Bad name --- this could be an attempt to rename a\n \t\t * ref that we used to allow to be created by accident.\n \t\t */\n-\t\tif (ref_exists(oldref.buf))\n-\t\t\trecovery = 1;\n-\t\telse\n-\t\t\tdie(_(\"Invalid branch name: '%s'\"), oldname);\n+\t\trecovery = 1;\n \t}\n \n \t/*\n@@ -487,9 +516,13 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \t * cause the worktree to become inconsistent with HEAD, so allow it.\n \t */\n \tif (!strcmp(oldname, newname))\n-\t\tvalidate_branchname(newname, &newref, 0);\n+\t\tres = validate_branchname(newname, &newref, 1);\n \telse\n-\t\tvalidate_new_branchname(newname, &newref, force, 0);\n+\t\tres = validate_new_branchname(newname, &newref, force, 1);\n+\n+\tget_error_msg(&error_msg, oldname, ref_exists(oldref.buf), newname, res);\n+\tif (strbuf_cmp(&error_msg, &empty))\n+\t\tdie(\"%s\", error_msg.buf);\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \n@@ -530,6 +563,8 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \t\tdie(_(\"Branch is copied, but update of config-file failed\"));\n \tstrbuf_release(&oldsection);\n \tstrbuf_release(&newsection);\n+\tstrbuf_release(&error_msg);\n+\tstrbuf_release(&empty);\n }\n \n static GIT_PATH_FUNC(edit_description, \"EDIT_DESCRIPTION\")\n-- \n2.15.0.461.gf957c703b.dirty\n\n"},{"id":"331656","messageId":"20171102065407.25404-2-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171102065407.25404-1-kaartic.sivaraam@gmail.com","subject":"[RFC PATCH v3 1/4] branch: improve documentation and naming of 'create_branch()'","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-02T06:54:04Z","receivedAt":"2017-11-02T06:54:54Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"From: Kaartic Sivaraam \n\nThe documentation for 'create_branch()' was incomplete as it didn't say\nwhat certain parameters were used for. Further a parameter name wasn't\nvery communicative.\n\nSo, add missing documentation for the sake of completeness and easy\nreference. Also, rename the concerned parameter to make its name more\ncommunicative.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 4 ++--\n branch.h | 7 ++++++-\n 2 files changed, 8 insertions(+), 3 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex fe1e1c367..ea6e2b359 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -244,7 +244,7 @@ N_(\"\\n\"\n \"\\\"git push -u\\\" to set the upstream config as you push.\");\n \n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog, int clobber_head,\n+\t\t int force, int reflog, int clobber_head_ok,\n \t\t int quiet, enum branch_track track)\n {\n \tstruct commit *commit;\n@@ -258,7 +258,7 @@ void create_branch(const char *name, const char *start_name,\n \tif (track == BRANCH_TRACK_EXPLICIT || track == BRANCH_TRACK_OVERRIDE)\n \t\texplicit_tracking = 1;\n \n-\tif ((track == BRANCH_TRACK_OVERRIDE || clobber_head)\n+\tif ((track == BRANCH_TRACK_OVERRIDE || clobber_head_ok)\n \t ? validate_branchname(name, &ref)\n \t : validate_new_branchname(name, &ref, force)) {\n \t\tif (!force)\ndiff --git a/branch.h b/branch.h\nindex be5e5d130..1512b78d1 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -15,12 +15,17 @@\n *\n * - reflog creates a reflog for the branch\n *\n+ * - clobber_head_ok allows the currently checked out (hence existing)\n+ * branch to be overwritten; without 'force', it has no effect.\n+ *\n+ * - quiet suppresses tracking information\n+ *\n * - track causes the new branch to be configured to merge the remote branch\n * that start_name is a tracking branch for (if any).\n */\n void create_branch(const char *name, const char *start_name,\n \t\t int force, int reflog,\n-\t\t int clobber_head, int quiet, enum branch_track track);\n+\t\t int clobber_head_ok, int quiet, enum branch_track track);\n \n /*\n * Check if 'name' can be a valid name for a branch; die otherwise.\n-- \n2.15.0.461.gf957c703b.dirty\n\n"},{"id":"331664","messageId":"e8a600d4-880b-4fb8-6901-78acbd720261@gmail.com","threadId":"46452","inReplyTo":"20171102065407.25404-4-kaartic.sivaraam@gmail.com","subject":"Re: [RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-02T08:39:30Z","receivedAt":"2017-11-02T08:39:44Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Thursday 02 November 2017 12:24 PM, Kaartic Sivaraam wrote:\n> Signed-off-by: Kaartic Sivaraam \n> Signed-off-by: Kaartic Sivaraam \n\nI just now saw this small glitch as a consequence of recently\nchanging my email address. I would prefer to keep the second one\nbut as the other patches have the first one it's better to keep\nthe first one for now.\n\nBut wait, it seems that this commit also has a different author\nidentity (the email adress part). If this is a big enough issue,\nI'll fix that and send a v4 (possibly with any other suggested\nchanges) else I'll leave it as it is.\n\nBTW, I added the Ccs to this mail which I forgot to do when\nsending the patches, hope it's not an issue.\n\n---\nKaartic\n\n"},{"id":"331668","messageId":"CAPig+cRJDiHXoz-81EMtsbFfqaZz76eo1msUQW+eBP=wUsm6JA@mail.gmail.com","threadId":"46452","inReplyTo":"20171102065407.25404-5-kaartic.sivaraam@gmail.com","subject":"Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2017-11-02T14:21:14Z","receivedAt":"2017-11-02T14:21:21Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Nov 2, 2017 at 2:54 AM, Kaartic Sivaraam\n wrote:\n> From: Kaartic Sivaraam \n>\n> When trying to rename an inexistent branch to with a name of a branch\n> that already exists the rename failed specifying the new branch name\n> exists rather than specifying that the branch trying to be renamed\n> doesn't exist.\n>\n> $ git branch -m tset master\n> fatal: A branch named 'master' already exists.\n>\n> It's conventional to report that 'tset' doesn't exist rather than\n> reporting that 'master' exists, the same way the 'mv' command does.\n>\n> (hypothetical)\n> $ git branch -m tset master\n> fatal: branch 'tset' doesn't exist.\n>\n> That has the problem that the error about an existing branch is shown\n> only after the user corrects the error about inexistent branch.\n>\n> $ git branch -m test master\n> fatal: A branch named 'master' already exists.\n>\n> This isn't useful either because the user would have corrected this error in\n> a single go if he had been told this alongside the first error. So, give\n> more useful error messages by giving errors about old branch name and new\n> branch name at the same time. This is possible as the branch name validation\n> functions now return the reason they were about to die, when requested.\n>\n> $ git branch -m tset master\n> fatal: branch 'tset' doesn't exist, and branch 'master' already exists\n\nNicely explained; easily understood.\n\n> Note: Thanks to the strbuf API that made it possible to easily construct\n> the composite error message strings!\n\nThis may be a problem. See below...\n\n> Signed-off-by: Kaartic Sivaraam \n> ---\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> +static void get_error_msg(struct strbuf* error_msg, const char* oldname, unsigned old_branch_exists,\n> + const char* newname, enum branch_validation_result res)\n> +{\n> + const char* connector_string = _(\", and \");\n> +\n> + if (!old_branch_exists) {\n> + strbuf_addf(error_msg, _(\"branch '%s' doesn't exist\"), oldname);\n> + }\n> +\n> + switch (res) {\n> + case BRANCH_EXISTS_NO_FORCE:\n> + strbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n> + strbuf_addf(error_msg,_(\"branch '%s' already exists\"), newname);\n> + break;\n> + case CANNOT_FORCE_UPDATE_CURRENT_BRANCH:\n> + strbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n> + strbuf_addstr(error_msg, _(\"cannot force update the current branch\"));\n> + break;\n> + case INVALID_BRANCH_NAME:\n> + strbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n> + strbuf_addf(error_msg, _(\"branch name '%s' is invalid\"), newname);\n> + break;\n> + /* not necessary to handle success cases */\n> + case BRANCH_EXISTS:\n> + case BRANCH_DOESNT_EXIST:\n> + break;\n> + }\n> +}\n\nTranslators can correct me, but this smells like \"sentence lego\"[1],\nwhich we'd like to avoid. Translators lack full context when presented\nwith bits and pieces of a sentence like this, thus the translation may\nbe of poor quality; it may even be entirely incorrect since they don't\nnecessarily know how you will be composing the various pieces.\n\nYou _might_ be able to able to resolve this by dropping \"and\" from:\n\n \"foo is moo, and bar is boo\"\n\nto turn the error messages into independent clauses:\n\n \"foo is moo; bar is boo\"\n\nbut I'm no translator, and even that may fail the lego sniff test.\n\nA sure-fire way to avoid lego construction would be simply to emit\neach messages on its own line:\n\n fatal: branch 'tset' doesn't exist\n fatal: branch 'master' already exists\n\n(though, you might consider that too ugly).\n\n[1]: http://www.gnu.org/software/gettext/manual/gettext.html#Preparing-Strings\n"},{"id":"331686","messageId":"CAGZ79kY-1PLf2aOeNOkPz_MNSPtJHTtj=9eC-xdbbLq+WZbkwg@mail.gmail.com","threadId":"46452","inReplyTo":"e8a600d4-880b-4fb8-6901-78acbd720261@gmail.com","subject":"Re: [RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-11-02T18:42:16Z","receivedAt":"2017-11-02T18:42:22Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Nov 2, 2017 at 1:39 AM, Kaartic Sivaraam\n wrote:\n> On Thursday 02 November 2017 12:24 PM, Kaartic Sivaraam wrote:\n>>\n>> Signed-off-by: Kaartic Sivaraam \n>> Signed-off-by: Kaartic Sivaraam \n>\n>\n> I just now saw this small glitch as a consequence of recently\n> changing my email address. I would prefer to keep the second one\n> but as the other patches have the first one it's better to keep\n> the first one for now.\n\nIf you prefer one of them, you may have incentive to\nadd an entry into .mailmap file, otherwise I'd kindly ask you\nto. :) (c.f. `git log --no-merges -- .mailmap`)\n\n> But wait, it seems that this commit also has a different author\n> identity (the email adress part). If this is a big enough issue,\n> I'll fix that and send a v4 (possibly with any other suggested\n> changes) else I'll leave it as it is.\n>\n> BTW, I added the Ccs to this mail which I forgot to do when\n> sending the patches, hope it's not an issue.\n"},{"id":"331760","messageId":"59d4a08d-7165-9e56-5ddc-4f97d4a9d4d4@gmail.com","threadId":"46452","inReplyTo":"CAPig+cRJDiHXoz-81EMtsbFfqaZz76eo1msUQW+eBP=wUsm6JA@mail.gmail.com","subject":"Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-03T02:41:21Z","receivedAt":"2017-11-03T02:41:33Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Thursday 02 November 2017 07:51 PM, Eric Sunshine wrote:\n> \n> Nicely explained; easily understood.\n>\n\nGood to hear that.\n\n\n> \n> Translators can correct me, but this smells like \"sentence lego\"[1],\n> which we'd like to avoid. Translators lack full context when presented\n> with bits and pieces of a sentence like this, thus the translation may\n> be of poor quality; it may even be entirely incorrect since they don't\n> necessarily know how you will be composing the various pieces.\n> \n> You _might_ be able to able to resolve this by dropping \"and\" from:\n> \n> \"foo is moo, and bar is boo\"\n> \n> to turn the error messages into independent clauses:\n> \n> \"foo is moo; bar is boo\"\n> > but I'm no translator, and even that may fail the lego sniff test.\n> \nThough I can't be very sure that the one you suggested will pass the \n\"lego sniff test\", its better than the \"and\" I used. Further, my \ninstinct says it wouldn't qualify as sentence lego (it's just a \";\").\n\n\n> A sure-fire way to avoid lego construction would be simply to emit\n> each messages on its own line:\n> \n> fatal: branch 'tset' doesn't exist\n> fatal: branch 'master' already exists\n> \n> (though, you might consider that too ugly).\n>\n\nThough it might not look that ugly, I don't know how you could make \n'git' die() twice (or am I missing something)! Of course we could use \n'error()' to report the errors and then 'die()' with a message like \n\"Branch rename failed\" but I find that to be a little too verbose and \nfurther using the connector \";\" instead of \"and\" does seem to reduce the \npossibilities for the above program fragment to pass the \"lego sniff test\".\n\n---\nKaartic\n"},{"id":"331761","messageId":"2aba29d1-3c6c-f04d-b284-991dbe15be54@gmail.com","threadId":"46452","inReplyTo":"CAGZ79kY-1PLf2aOeNOkPz_MNSPtJHTtj=9eC-xdbbLq+WZbkwg@mail.gmail.com","subject":"Re: [RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-03T02:58:56Z","receivedAt":"2017-11-03T02:59:10Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Friday 03 November 2017 12:12 AM, Stefan Beller wrote:\n> On Thu, Nov 2, 2017 at 1:39 AM, Kaartic Sivaraam\n> wrote:\n>> On Thursday 02 November 2017 12:24 PM, Kaartic Sivaraam wrote:\n>>>\n>>> Signed-off-by: Kaartic Sivaraam \n>>> Signed-off-by: Kaartic Sivaraam \n>>\n>>\n>> I just now saw this small glitch as a consequence of recently\n>> changing my email address. I would prefer to keep the second one\n>> but as the other patches have the first one it's better to keep\n>> the first one for now.\n> \n> If you prefer one of them, you may have incentive to\n> add an entry into .mailmap file, otherwise I'd kindly ask you\n> to. :) (c.f. `git log --no-merges -- .mailmap`)\n> \n\nSure, I'll do that. My intuition says this doesn't remove the duplicated \n sign-off line. Anyways, there's for sure a v4 that's going to update \nthe connector string in [4/4] and another update. I'll be careful to \naddress these issues in v4.\n\n---\nKaartic\n\n"},{"id":"331898","messageId":"xmqqbmkgjh32.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"20171102065407.25404-3-kaartic.sivaraam@gmail.com","subject":"Re: [RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-06T02:06:57Z","receivedAt":"2017-11-06T02:07:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> From: Kaartic Sivaraam \n>\n> The ad-hoc patches to add new arguments to a function when needed\n> resulted in the related arguments not being close to each other.\n> This misleads the person reading the code to believe that there isn't\n> much relation between those arguments while it's not the case.\n\nI do not get what this wants to say. \"I am sending this ad-hoc\npatch that scrambles the order of parameters for no real reason\" is\ncertainly not how you are selling this step.\n\n> So, re-order the arguments to keep the related arguments close to each\n> other.\n\nThis sentence (without \"So,\", obviously, because I do not get the\nprevious paragraph) I do understand and agree with as a goal.\n\nI think the only two things that should be kept together are \"force\"\nand \"clobber_head_ok\" because the previous 1/4 changed the meaning\nof \"clobber_head\" to \"it is OK if I am renaming the currently\nchecked-out branch\", i.e. closer to what \"force\" means.\n\nI certainly would not mind the order used in the result of this\npatch (in other words, if somebody posted a patch to add\ncreate_branch() function to the codebase that lacked it, with its\nparameters listed in the order this patch uses, I wouldn't\ncomplain), but it would have equally been OK if \"reflog\" and \"force\"\nwere swapped without making any other change this patch makes.\n\nI dunno.\n\n> Signed-off-by: Kaartic Sivaraam \n> ---\n> branch.c | 4 ++--\n> branch.h | 14 +++++++-------\n> builtin/branch.c | 4 ++--\n> builtin/checkout.c | 6 +++---\n> 4 files changed, 14 insertions(+), 14 deletions(-)\n>\n> diff --git a/branch.c b/branch.c\n> index ea6e2b359..7c8093041 100644\n> --- a/branch.c\n> +++ b/branch.c\n> @@ -244,8 +244,8 @@ N_(\"\\n\"\n> \"\\\"git push -u\\\" to set the upstream config as you push.\");\n> \n> void create_branch(const char *name, const char *start_name,\n> -\t\t int force, int reflog, int clobber_head_ok,\n> -\t\t int quiet, enum branch_track track)\n> +\t\t enum branch_track track, int force, int clobber_head_ok,\n> +\t\t int reflog, int quiet)\n> {\n> \tstruct commit *commit;\n> \tstruct object_id oid;\n> diff --git a/branch.h b/branch.h\n> index 1512b78d1..85052628b 100644\n> --- a/branch.h\n> +++ b/branch.h\n> @@ -11,21 +11,21 @@\n> * - start_name is the name of the existing branch that the new branch should\n> * start from\n> *\n> - * - force enables overwriting an existing (non-head) branch\n> + * - track causes the new branch to be configured to merge the remote branch\n> + * that start_name is a tracking branch for (if any).\n> *\n> - * - reflog creates a reflog for the branch\n> + * - force enables overwriting an existing (non-head) branch\n> *\n> * - clobber_head_ok allows the currently checked out (hence existing)\n> * branch to be overwritten; without 'force', it has no effect.\n> *\n> - * - quiet suppresses tracking information\n> + * - reflog creates a reflog for the branch\n> *\n> - * - track causes the new branch to be configured to merge the remote branch\n> - * that start_name is a tracking branch for (if any).\n> + * - quiet suppresses tracking information\n> */\n> void create_branch(const char *name, const char *start_name,\n> -\t\t int force, int reflog,\n> -\t\t int clobber_head_ok, int quiet, enum branch_track track);\n> +\t\t enum branch_track track, int force, int clobber_head_ok,\n> +\t\t int reflog, int quiet);\n> \n> /*\n> * Check if 'name' can be a valid name for a branch; die otherwise.\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index 5be40b384..df06ac968 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -766,7 +766,7 @@ 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\t */\n> -\t\tcreate_branch(branch->name, new_upstream, 0, 0, 0, quiet, BRANCH_TRACK_OVERRIDE);\n> +\t\tcreate_branch(branch->name, new_upstream, BRANCH_TRACK_OVERRIDE, 0, 0, 0, quiet);\n> \t} else if (unset_upstream) {\n> \t\tstruct branch *branch = branch_get(argv[0]);\n> \t\tstruct strbuf buf = STRBUF_INIT;\n> @@ -806,7 +806,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n> \t\t\tdie(_(\"the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.\"));\n> \n> \t\tcreate_branch(argv[0], (argc == 2) ? argv[1] : head,\n> -\t\t\t force, reflog, 0, quiet, track);\n> +\t\t\t track, force, 0, reflog, quiet);\n> \n> \t} else\n> \t\tusage_with_options(builtin_branch_usage, options);\n> diff --git a/builtin/checkout.c b/builtin/checkout.c\n> index 8546d630b..5c34a9a0d 100644\n> --- a/builtin/checkout.c\n> +++ b/builtin/checkout.c\n> @@ -639,11 +639,11 @@ static void update_refs_for_switch(const struct checkout_opts *opts,\n> \t\t}\n> \t\telse\n> \t\t\tcreate_branch(opts->new_branch, new->name,\n> +\t\t\t\t opts->track,\n> +\t\t\t\t opts->new_branch_force ? 1 : 0,\n> \t\t\t\t opts->new_branch_force ? 1 : 0,\n> \t\t\t\t opts->new_branch_log,\n> -\t\t\t\t opts->new_branch_force ? 1 : 0,\n> -\t\t\t\t opts->quiet,\n> -\t\t\t\t opts->track);\n> +\t\t\t\t opts->quiet);\n> \t\tnew->name = opts->new_branch;\n> \t\tsetup_branch_path(new);\n> \t}\n"},{"id":"331899","messageId":"xmqq7ev4jga9.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"20171102065407.25404-4-kaartic.sivaraam@gmail.com","subject":"Re: [RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-06T02:24:14Z","receivedAt":"2017-11-06T02:24:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> This parameter allows the branchname validation functions to\n> optionally return a flag specifying the reason for failure, when\n> requested. This allows the caller to know why it was about to die.\n> This allows more useful error messages to be given to the user when\n> trying to rename a branch.\n>\n> The flags are specified in the form of an enum and values for success\n> flags have been assigned explicitly to clearly express that certain\n> callers rely on those values and they cannot be arbitrary.\n>\n> Only the logic has been added but no caller has been made to use it, yet.\n> So, no functional changes.\n\nThis step makes sense, and nicely done.\n\nWe usually use the word \"gently\" to when we enhance an operation\nthat used to always die on failure. When there are tons of callsite\nto the original operation F(), we introduce F_gently() variant and\ndo something like\n\n\tF(...)\n\t{\n\t\tif (F_gently(...))\n\t\t\tdie(...);\n\t}\n\nso that the callers do not have to change. If there aren't that\nmany, it is OK to change the function signature of F() to tell it\nnot to die without adding a new F_gently() function, which is the\napproach more appropriate for this change. The extra parameter used\nfor that purpose should be called \"gently\", perhaps.\n\n> +\tif(ref_exists(ref->buf))\n> +\t\treturn BRANCH_EXISTS;\n> +\telse\n> +\t\treturn BRANCH_DOESNT_EXIST;\n\nAlways have SP between \"if\" (and other keyword like \"while\") and its\ncondition.\n\nFor this one, however, this might be easier to follow:\n\n\treturn ref_exists(ref->buf) ? BRANCH_EXISTS : BRANCH_DOESNT_EXIST;\n\nThe names of the enum values may need further thought. They must\nclearly convey two things, in addition to what kind of status they\nrepresent; the current names only convey the status. From the names\nof these values, it must be clear that they are part of the same\nenum (e.g. by sharing a common prefix), and also from the names of\nthese values, it must be clear which ones are error conditions and\nwhich are not, without knowing their actual values. A reader cannot\nimmediately tell from \"BRANCH_EXISTS\" if that is a good thing or\nnot.\n\nOther than that, looks fairly cleanly done. I like what this step\nwants to achieve.\n\nThanks.\n\n"},{"id":"331900","messageId":"xmqq375sjfzk.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"20171102065407.25404-5-kaartic.sivaraam@gmail.com","subject":"Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-06T02:30:39Z","receivedAt":"2017-11-06T02:30:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> index 7018e5d75..c2bbf8c3d 100644\n> --- a/builtin/branch.c\n> +++ b/builtin/branch.c\n> @@ -458,11 +458,42 @@ static void reject_rebase_or_bisect_branch(const char *target)\n> \tfree_worktrees(worktrees);\n> }\n> \n> +static void get_error_msg(struct strbuf* error_msg, const char* oldname, unsigned old_branch_exists,\n> +\t\t\t const char* newname, enum branch_validation_result res)\n> +{\n> +\tconst char* connector_string = _(\", and \");\n> +\n> +\tif (!old_branch_exists) {\n> +\t\tstrbuf_addf(error_msg, _(\"branch '%s' doesn't exist\"), oldname);\n> +\t}\n\nNo {} around a single statement block of \"if\", especially when there\nis no \"else\" that has multi-statement block that needs {}.\n\n> +\tswitch (res) {\n> +\t\tcase BRANCH_EXISTS_NO_FORCE:\n> +\t\t\tstrbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n> +\t\t\tstrbuf_addf(error_msg,_(\"branch '%s' already exists\"), newname);\n> +\t\t\tbreak;\n\nThe case arms and their statements are indented by one level too much.\nThe lines are getting overlong. Find a good place to split, e.g.\n\n \t\tstrbuf_addf(error_msg, \"%s\",\n\t\t\t!old_branch_exists ? connector_string : \"\");\n\nLeave a single SP after each \",\" in an arguments list.\n\nAs Eric pointed out, this certainly smells like a sentence lego that\nwe would be better off without.\n\n> static void copy_or_rename_branch(const char *oldname, const char *newname, int copy, int force)\n> {\n> \tstruct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n> \tstruct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n> \tint recovery = 0;\n> +\tstruct strbuf error_msg = STRBUF_INIT, empty = STRBUF_INIT;\n> +\tenum branch_validation_result res;\n> \n> \tif (!oldname) {\n> \t\tif (copy)\n> @@ -471,15 +502,13 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n> \t\t\tdie(_(\"cannot rename the current branch while not on any.\"));\n> \t}\n> \n> -\tif (strbuf_check_branch_ref(&oldref, oldname)) {\n> +\tif (strbuf_check_branch_ref(&oldref, oldname) && ref_exists(oldref.buf))\n> +\t{\n\nOpening brace { that begins a block comes at the end of the line\nthat closes the condition of \"if\"; if you found that your line is\noverlong, perhaps do it like so instead:\n\n\tif (strbuf_check_branch_ref(&oldref, oldname) &&\n\t ref_exists(oldref.buf)) {\n"},{"id":"332325","messageId":"1510493270.2683.6.camel@gmail.com","threadId":"46452","inReplyTo":"xmqqbmkgjh32.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-12T13:27:50Z","receivedAt":"2017-11-12T13:28:05Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Mon, 2017-11-06 at 11:06 +0900, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n> \n> > From: Kaartic Sivaraam \n> > \n> > The ad-hoc patches to add new arguments to a function when needed\n> > resulted in the related arguments not being close to each other.\n> > This misleads the person reading the code to believe that there isn't\n> > much relation between those arguments while it's not the case.\n> \n> I do not get what this wants to say. \"I am sending this ad-hoc\n> patch that scrambles the order of parameters for no real reason\" is\n> certainly not how you are selling this step.\n> \n> > So, re-order the arguments to keep the related arguments close to each\n> > other.\n> \n> This sentence (without \"So,\", obviously, because I do not get the\n> previous paragraph) I do understand and agree with as a goal.\n> \n\nI've tried to improve it, does the following paragraph sound clear\nenough?\n\n branch: group related arguments of create_branch()\n \n New arguments were added to create_branch() whenever the need\n arised and they were added to tail of the argument list. This\n resulted in the related arguments not being close to each other.\n This misleads the person reading the code to believe that\n there isn't much relation between those arguments while it is\n not the case.\n \n So, re-order the arguments to keep the related arguments close\n to each other.\n\n\n> I think the only two things that should be kept together are \"force\"\n> and \"clobber_head_ok\" because the previous 1/4 changed the meaning\n> of \"clobber_head\" to \"it is OK if I am renaming the currently\n> checked-out branch\", i.e. closer to what \"force\" means.\n> \n> I certainly would not mind the order used in the result of this\n> patch (in other words, if somebody posted a patch to add\n> create_branch() function to the codebase that lacked it, with its\n> parameters listed in the order this patch uses, I wouldn't\n> complain), but it would have equally been OK if \"reflog\" and \"force\"\n> were swapped without making any other change this patch makes.\n> \n\nMakes sense. The unwanted shuffling was a consequence of my attempt to\nsee if the signature of the function did change when the position of\nthe 'enum' was changed. It seems there isn't change in its signature as\nit is possible to use integers for enums and vice versa due to liberal\nchecking for misuses.\n\nI've changed the signature back to keep alone \"force\" and\n\"clobber_head_ok\" together.\n\n\nThanks,\nKaartic\n"},{"id":"332326","messageId":"1510493595.2683.9.camel@gmail.com","threadId":"46452","inReplyTo":"xmqq7ev4jga9.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-12T13:33:15Z","receivedAt":"2017-11-12T13:33:27Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Mon, 2017-11-06 at 11:24 +0900, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n> \n> We usually use the word \"gently\" to when we enhance an operation\n> that used to always die on failure. When there are tons of callsite\n> to the original operation F(), we introduce F_gently() variant and\n> do something like\n> \n> \tF(...)\n> \t{\n> \t\tif (F_gently(...))\n> \t\t\tdie(...);\n> \t}\n> \n> so that the callers do not have to change. If there aren't that\n> many, it is OK to change the function signature of F() to tell it\n> not to die without adding a new F_gently() function, which is the\n> approach more appropriate for this change. The extra parameter used\n> for that purpose should be called \"gently\", perhaps.\n> \n\nGood suggestion, wasn't aware of it before. Renamed it.\n\n\n> > +\tif(ref_exists(ref->buf))\n> > +\t\treturn BRANCH_EXISTS;\n> > +\telse\n> > +\t\treturn BRANCH_DOESNT_EXIST;\n> \n> Always have SP between \"if\" (and other keyword like \"while\") and its\n> condition.\n>\n> For this one, however, this might be easier to follow:\n> \n> \treturn ref_exists(ref->buf) ? BRANCH_EXISTS : BRANCH_DOESNT_EXIST;\n> \n\nDone.\n\n\n> The names of the enum values may need further thought. They must\n> clearly convey two things, in addition to what kind of status they\n> represent; the current names only convey the status. From the names\n> of these values, it must be clear that they are part of the same\n> enum (e.g. by sharing a common prefix), and also from the names of\n> these values, it must be clear which ones are error conditions and\n> which are not, without knowing their actual values. A reader cannot\n> immediately tell from \"BRANCH_EXISTS\" if that is a good thing or\n> not.\n> \n\nI've added the prefix of \"VALIDATION_{FAIL,PASS}\" as appropriate to the\nenum values. This made the names to have the form,\n\n VALIDATION_(kind of status)_(reason)\n\nThis made the names a bit long but I couldn't come up with a better\nprefix for now. Any suggestions are welcome.\n\n\nThanks for the detailed review!\n\n---\nKaartic\n"},{"id":"332330","messageId":"1510495525.2683.12.camel@gmail.com","threadId":"46452","inReplyTo":"xmqq375sjfzk.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-12T14:05:25Z","receivedAt":"2017-11-12T14:05:40Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Mon, 2017-11-06 at 11:30 +0900, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n> \n> No {} around a single statement block of \"if\", especially when there\n> is no \"else\" that has multi-statement block that needs {}.\n> \n\nThe code has changed a little since v3 so this if has been replaced\nwith a switch case.\n\n\n> > +\tswitch (res) {\n> > +\t\tcase BRANCH_EXISTS_NO_FORCE:\n> > +\t\t\tstrbuf_addf(error_msg, \"%s\", (!old_branch_exists) ? connector_string : \"\");\n> > +\t\t\tstrbuf_addf(error_msg,_(\"branch '%s' already exists\"), newname);\n> > +\t\t\tbreak;\n> \n> The case arms and their statements are indented by one level too much.\n> The lines are getting overlong. Find a good place to split, e.g.\n> \n> \t\tstrbuf_addf(error_msg, \"%s\",\n> \t\t\t!old_branch_exists ? connector_string : \"\");\n> \n> Leave a single SP after each \",\" in an arguments list.\n> \n\nFixed these.\n\n\n> As Eric pointed out, this certainly smells like a sentence lego that\n> we would be better off without.\n> \n\nAs stated in that mail, I've replaced the connector \" and \" with \"; \"\nas it seemed to be the most simple way to overcome the issue, at least\nin my opinion. In case there's any better way to fix this let me know.\n\n\n> > static void copy_or_rename_branch(const char *oldname, const char *newname, int copy, int force)\n> > {\n> > \tstruct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n> > \tstruct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n> > \tint recovery = 0;\n> > +\tstruct strbuf error_msg = STRBUF_INIT, empty = STRBUF_INIT;\n> > +\tenum branch_validation_result res;\n> > \n> > \tif (!oldname) {\n> > \t\tif (copy)\n> > @@ -471,15 +502,13 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n> > \t\t\tdie(_(\"cannot rename the current branch while not on any.\"));\n> > \t}\n> > \n> > -\tif (strbuf_check_branch_ref(&oldref, oldname)) {\n> > +\tif (strbuf_check_branch_ref(&oldref, oldname) && ref_exists(oldref.buf))\n> > +\t{\n> \n> Opening brace { that begins a block comes at the end of the line\n> that closes the condition of \"if\"; if you found that your line is\n> overlong, perhaps do it like so instead:\n> \n> \tif (strbuf_check_branch_ref(&oldref, oldname) &&\n> \t ref_exists(oldref.buf)) {\n\nThis part changed too. Anyways thanks for the detailed review :-)\n\n-- \nKaartic\n"},{"id":"332353","messageId":"20171112182322.GA17612@alpha.vpn.ikke.info","threadId":"46452","inReplyTo":"20171102065407.25404-5-kaartic.sivaraam@gmail.com","subject":"Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2017-11-12T18:23:22Z","receivedAt":"2017-11-12T18:23:29Z","isPatch":true,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Thu, Nov 02, 2017 at 12:24:07PM +0530, Kaartic Sivaraam wrote:\n> From: Kaartic Sivaraam \n> \n> When trying to rename an inexistent branch to with a name of a branch\n\nThis sentence does not read well. Probably s/with a/the/ helps.\n\n> that already exists the rename failed specifying the new branch name\n> exists rather than specifying that the branch trying to be renamed\n> doesn't exist.\n> \n> [..]\n> \n> Note: Thanks to the strbuf API that made it possible to easily construct\n> the composite error message strings!\n\nI'm not sure this note adds a lot, since the strbuf API is not that new.\n\nKevin\n"},{"id":"332380","messageId":"29bd81e4-e8df-8fb8-9436-d70902106f49@gmail.com","threadId":"46452","inReplyTo":"20171112182322.GA17612@alpha.vpn.ikke.info","subject":"Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-13T02:31:12Z","receivedAt":"2017-11-13T02:32:46Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Sunday 12 November 2017 11:53 PM, Kevin Daudt wrote:\n> On Thu, Nov 02, 2017 at 12:24:07PM +0530, Kaartic Sivaraam wrote:\n>> From: Kaartic Sivaraam \n>>\n>> When trying to rename an inexistent branch to with a name of a branch\n>\n> This sentence does not read well. Probably s/with a/the/ helps.\n>\n\nThanks. Seems I missed it somehow. Will fix it.\n\n>> that already exists the rename failed specifying the new branch name\n>> exists rather than specifying that the branch trying to be renamed\n>> doesn't exist.\n>>\n>> [..]\n>>\n>> Note: Thanks to the strbuf API that made it possible to easily construct\n>> the composite error message strings!\n>\n> I'm not sure this note adds a lot, since the strbuf API is not that new.\n>\n\nThat was a little attribution I wanted make to the strbuf API as this \nwas the first time I leveraged it to this extent and I was surprised by \nthe way it made string manipulation easier in C. Just documented my \nexcitation. In case it seems to be noise (?) which should removed, let \nme know.\n\n---\nKaartic\n"},{"id":"332381","messageId":"xmqqefp2c3i0.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"1510493270.2683.6.camel@gmail.com","subject":"Re: [RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-13T02:32:39Z","receivedAt":"2017-11-13T02:32:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> I've tried to improve it, does the following paragraph sound clear\n> enough?\n>\n> branch: group related arguments of create_branch()\n> \n> New arguments were added to create_branch() whenever the need\n> arised and they were added to tail of the argument list. This\n> resulted in the related arguments not being close to each other.\n\nOK, I understand what you wanted to say. But I do not think that is\nbased on a true history.\n\n - f9a482e6 (\"checkout: suppress tracking message with \"-q\"\",\n 2012-03-26) adds 'quiet' just after 'clobber_head', exactly\n because they are related, and leaves 'track' at the end.\n\n - 39bd6f72 (\"Allow checkout -B to update the\n current branch\", 2011-11-26) adds 'clobber_head' not at the end but\n before 'track', which is left at the end. \n\n - c847f537 (\"Detached HEAD (experimental)\", 2007-01-01) split 'start'\n into 'start_name' and 'start_sha1' (the latter was laster removed)\n and this was not a mindless \"add at the end\", either.\n\n - 0746d19a (\"git-branch, git-checkout: autosetup for remote branch\n tracking\", 2007-03-08) did add track at the end, but that is\n justifiable, as it has no relation to any other parameter.\n\nYou could call 39bd6f72 somewhat questionable as 'clobber_head' is\nrelated to 'force' more strongly than it is to 'reflog' [*1*], but\nit is unfair to blame anything else having done a mindless \"add at\nthe end\".\n\n\n\n[Footnote]\n\n*1* I actually think the commit added 'clobber_head' because for the\n purpose of what the commit did, it closely was related to 'track',\n turning into .\n Arguably, it could have done instead.\n\n"},{"id":"332384","messageId":"1510542413.5134.2.camel@gmail.com","threadId":"46452","inReplyTo":"xmqqefp2c3i0.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-13T03:06:53Z","receivedAt":"2017-11-13T03:07:06Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Mon, 2017-11-13 at 11:32 +0900, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n> \n> > I've tried to improve it, does the following paragraph sound clear\n> > enough?\n> > \n> > branch: group related arguments of create_branch()\n> > \n> > New arguments were added to create_branch() whenever the need\n> > arised and they were added to tail of the argument list. This\n> > resulted in the related arguments not being close to each other.\n> \n> OK, I understand what you wanted to say. But I do not think that is\n> based on a true history.\n> \n> - f9a482e6 (\"checkout: suppress tracking message with \"-q\"\",\n> 2012-03-26) adds 'quiet' just after 'clobber_head', exactly\n> because they are related, and leaves 'track' at the end.\n> \n> - 39bd6f72 (\"Allow checkout -B to update the\n> current branch\", 2011-11-26) adds 'clobber_head' not at the end but\n> before 'track', which is left at the end. \n> \n> - c847f537 (\"Detached HEAD (experimental)\", 2007-01-01) split 'start'\n> into 'start_name' and 'start_sha1' (the latter was laster removed)\n> and this was not a mindless \"add at the end\", either.\n> \n> - 0746d19a (\"git-branch, git-checkout: autosetup for remote branch\n> tracking\", 2007-03-08) did add track at the end, but that is\n> justifiable, as it has no relation to any other parameter.\n> \n\nSeems I wasn't careful enough in noticing how the arguments were added.\nI seemed to have overlooked the fact that 39bd6f72 added 'clobber_head'\n\"before\" track which resulted in the vague commit message. Anyways,\nthanks for taking the time to dig into this.\n\n\n> You could call 39bd6f72 somewhat questionable as 'clobber_head' is\n> related to 'force' more strongly than it is to 'reflog' [*1*], but\n> it is unfair to blame anything else having done a mindless \"add at\n> the end\".\n> \n\nYep, you're right. How does the following sound?\n\n    branch: group related arguments of create_branch()\n    \n    39bd6f726 (Allow checkout -B to update the current\n    branch, 2011-11-26) added 'clobber_head' (now, 'clobber_head_ok')\n    \"before\" 'track' as 'track' was closely related 'clobber_head' for\n    the purpose the commit wanted to achieve. Looking from the perspective\n    of how the arguments are used it turns out that 'clobber_head' is\n    more related to 'force' than it is to 'track'.\n    \n    So, re-order the arguments to keep the related arguments close\n    to each other.\n    \n-- \nKaartic\n"},{"id":"332413","messageId":"20171113113018.GB17612@alpha.vpn.ikke.info","threadId":"46452","inReplyTo":"29bd81e4-e8df-8fb8-9436-d70902106f49@gmail.com","subject":"Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2017-11-13T11:30:18Z","receivedAt":"2017-11-13T11:30:25Z","isPatch":true,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Mon, Nov 13, 2017 at 08:01:12AM +0530, Kaartic Sivaraam wrote:\n> On Sunday 12 November 2017 11:53 PM, Kevin Daudt wrote:\n> > On Thu, Nov 02, 2017 at 12:24:07PM +0530, Kaartic Sivaraam wrote:\n> > > From: Kaartic Sivaraam \n> > > \n> > > When trying to rename an inexistent branch to with a name of a branch\n> > \n> > This sentence does not read well. Probably s/with a/the/ helps.\n> > \n> \n> Thanks. Seems I missed it somehow. Will fix it.\n> \n> > > that already exists the rename failed specifying the new branch name\n> > > exists rather than specifying that the branch trying to be renamed\n> > > doesn't exist.\n> > > \n> > > [..]\n> > > \n> > > Note: Thanks to the strbuf API that made it possible to easily construct\n> > > the composite error message strings!\n> > \n> > I'm not sure this note adds a lot, since the strbuf API is not that new.\n> > \n> \n> That was a little attribution I wanted make to the strbuf API as this was\n> the first time I leveraged it to this extent and I was surprised by the way\n> it made string manipulation easier in C. Just documented my excitation. In\n> case it seems to be noise (?) which should removed, let me know.\n\nI guess that would fit better below the the ---\n"},{"id":"332508","messageId":"5a0edab6-4e34-e9aa-4a27-0a19606b9b8d@gmail.com","threadId":"46452","inReplyTo":"20171113113018.GB17612@alpha.vpn.ikke.info","subject":"Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-14T05:25:21Z","receivedAt":"2017-11-14T05:25:34Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Monday 13 November 2017 05:00 PM, Kevin Daudt wrote:\n> On Mon, Nov 13, 2017 at 08:01:12AM +0530, Kaartic Sivaraam wrote:\n>> That was a little attribution I wanted make to the strbuf API as this was\n>> the first time I leveraged it to this extent and I was surprised by the way\n>> it made string manipulation easier in C. Just documented my excitation. In\n>> case it seems to be noise (?) which should removed, let me know.\n>\n> I guess that would fit better below the the ---\n>\n\nThat's a nice point. Thanks. (Why didn't I think of it before)\n\n\n---\nKaartic\n"},{"id":"332803","messageId":"20171118172648.17918-1-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171102065407.25404-1-kaartic.sivaraam@gmail.com","subject":"[PATCH 0/4] cleanups surrounding branch","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-18T17:26:44Z","receivedAt":"2017-11-18T17:27:53Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On the process of making 'git' give more useful error messages\nwhen trying to rename a branch[0], I found a few things that could\nbe cleaned up. After noticing that the cleanup commits exceeded\nthe commits that are related to the series, I thought it would\nbe better to separate the cleanups into an independent series\nto keep that topic focused on improving the error messages.\n\n1/4 and 2/4 were part of that series until v3. The others are new\ncleanups.\n\nThis series goes on top of 'master' and can be found in my fork\nas branch 'work/branch-cleanups'[1].\n\nNote: 1/4 might possibly have some conflicts with jc/branch-name-sanity\n\nFootnotes:\n\n[0]: cf. <20171102065407.25404-1-kaartic.sivaraam@gmail.com>\n\n[1]: https://github.com/sivaraam/git/tree/work/branch-cleanups\n\n\nKaartic Sivaraam (4):\n branch: improve documentation and naming of create_branch() parameters\n branch: group related arguments of create_branch()\n branch: update warning message shown when copying a misnamed branch\n builtin/branch: strip refs/heads/ using skip_prefix\n\n branch.c | 4 ++--\n branch.h | 10 ++++++++--\n builtin/branch.c | 20 +++++++++++++-------\n builtin/checkout.c | 2 +-\n 4 files changed, 24 insertions(+), 12 deletions(-)\n\n-- \n2.15.0.291.g0d8980c5d\n\n"},{"id":"332804","messageId":"20171118172648.17918-2-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171118172648.17918-1-kaartic.sivaraam@gmail.com","subject":"[PATCH 1/4] branch: improve documentation and naming of create_branch() parameters","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-18T17:26:45Z","receivedAt":"2017-11-18T17:27:59Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The documentation for 'create_branch()' was incomplete as it didn't say\nwhat certain parameters were used for. Further a parameter name wasn't\nvery communicative.\n\nSo, add missing documentation for the sake of completeness and easy\nreference. Also, rename the concerned parameter to make its name more\ncommunicative.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 4 ++--\n branch.h | 7 ++++++-\n 2 files changed, 8 insertions(+), 3 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 62f7b0d8c..3e8d2f93f 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -228,7 +228,7 @@ N_(\"\\n\"\n \"\\\"git push -u\\\" to set the upstream config as you push.\");\n \n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog, int clobber_head,\n+\t\t int force, int reflog, int clobber_head_ok,\n \t\t int quiet, enum branch_track track)\n {\n \tstruct commit *commit;\n@@ -244,7 +244,7 @@ void create_branch(const char *name, const char *start_name,\n \n \tif (validate_new_branchname(name, &ref, force,\n \t\t\t\t track == BRANCH_TRACK_OVERRIDE ||\n-\t\t\t\t clobber_head)) {\n+\t\t\t\t clobber_head_ok)) {\n \t\tif (!force)\n \t\t\tdont_change_ref = 1;\n \t\telse\ndiff --git a/branch.h b/branch.h\nindex b07788558..cb6411f84 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -15,12 +15,17 @@\n *\n * - reflog creates a reflog for the branch\n *\n+ * - clobber_head_ok allows the currently checked out (hence existing)\n+ * branch to be overwritten; without 'force', it has no effect.\n+ *\n+ * - quiet suppresses tracking information\n+ *\n * - track causes the new branch to be configured to merge the remote branch\n * that start_name is a tracking branch for (if any).\n */\n void create_branch(const char *name, const char *start_name,\n \t\t int force, int reflog,\n-\t\t int clobber_head, int quiet, enum branch_track track);\n+\t\t int clobber_head_ok, int quiet, enum branch_track track);\n \n /*\n * Validates that the requested branch may be created, returning the\n-- \n2.15.0.291.g0d8980c5d\n\n"},{"id":"332805","messageId":"20171118172648.17918-3-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171118172648.17918-1-kaartic.sivaraam@gmail.com","subject":"[PATCH 2/4] branch: group related arguments of create_branch()","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-18T17:26:46Z","receivedAt":"2017-11-18T17:28:04Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"39bd6f726 (Allow checkout -B to update the current\nbranch, 2011-11-26) added 'clobber_head' (now, 'clobber_head_ok')\n\"before\" 'track' as 'track' was closely related 'clobber_head' for\nthe purpose the commit wanted to achieve. Looking from the perspective\nof how the arguments are used it turns out that 'clobber_head' is\nmore related to 'force' than it is to 'track'.\n\nSo, re-order the arguments to keep the related arguments close\nto each other.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 2 +-\n branch.h | 9 +++++----\n builtin/branch.c | 2 +-\n builtin/checkout.c | 2 +-\n 4 files changed, 8 insertions(+), 7 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 3e8d2f93f..bd607ae97 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -228,7 +228,7 @@ N_(\"\\n\"\n \"\\\"git push -u\\\" to set the upstream config as you push.\");\n \n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog, int clobber_head_ok,\n+\t\t int force, int clobber_head_ok, int reflog,\n \t\t int quiet, enum branch_track track)\n {\n \tstruct commit *commit;\ndiff --git a/branch.h b/branch.h\nindex cb6411f84..f66536a10 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -13,19 +13,20 @@\n *\n * - force enables overwriting an existing (non-head) branch\n *\n- * - reflog creates a reflog for the branch\n- *\n * - clobber_head_ok allows the currently checked out (hence existing)\n * branch to be overwritten; without 'force', it has no effect.\n *\n+ * - reflog creates a reflog for the branch\n+ *\n * - quiet suppresses tracking information\n *\n * - track causes the new branch to be configured to merge the remote branch\n * that start_name is a tracking branch for (if any).\n+ *\n */\n void create_branch(const char *name, const char *start_name,\n-\t\t int force, int reflog,\n-\t\t int clobber_head_ok, int quiet, enum branch_track track);\n+\t\t int force, int clobber_head_ok,\n+\t\t int reflog, int quiet, enum branch_track track);\n \n /*\n * Validates that the requested branch may be created, returning the\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 33fd5fcfd..4edef5baa 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -806,7 +806,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tdie(_(\"the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.\"));\n \n \t\tcreate_branch(argv[0], (argc == 2) ? argv[1] : head,\n-\t\t\t force, reflog, 0, quiet, track);\n+\t\t\t force, 0, reflog, quiet, track);\n \n \t} else\n \t\tusage_with_options(builtin_branch_usage, options);\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 7d8bcc383..6068f8d8c 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -640,8 +640,8 @@ static void update_refs_for_switch(const struct checkout_opts *opts,\n \t\telse\n \t\t\tcreate_branch(opts->new_branch, new->name,\n \t\t\t\t opts->new_branch_force ? 1 : 0,\n-\t\t\t\t opts->new_branch_log,\n \t\t\t\t opts->new_branch_force ? 1 : 0,\n+\t\t\t\t opts->new_branch_log,\n \t\t\t\t opts->quiet,\n \t\t\t\t opts->track);\n \t\tnew->name = opts->new_branch;\n-- \n2.15.0.291.g0d8980c5d\n\n"},{"id":"332806","messageId":"20171118172648.17918-4-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171118172648.17918-1-kaartic.sivaraam@gmail.com","subject":"[PATCH 3/4] branch: update warning message shown when copying a misnamed branch","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-18T17:26:47Z","receivedAt":"2017-11-18T17:28:08Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"When a user tries to rename a branch that has a \"bad name\" (e.g.,\nstarts with a '-') then we warn them that the misnamed branch has\nbeen renamed \"away\". A similar message is shown when trying to create\na copy of a misnamed branch even though it doesn't remove the misnamed\nbranch. This is not correct and may confuse the user.\n\nSo, update the warning message shown to be more precise that only a copy\nof the misnamed branch has been created. It's better to show the warning\nmessage than not showing it at all as it makes the user aware of the\npresence of a misnamed branch.\n\nSigned-off-by: Kaartic Sivaraam \n---\n builtin/branch.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 4edef5baa..ca9d8abd0 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -507,7 +507,7 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \n \tif (recovery) {\n \t\tif (copy)\n-\t\t\twarning(_(\"Copied a misnamed branch '%s' away\"),\n+\t\t\twarning(_(\"Created a copy of a misnamed branch '%s'\"),\n \t\t\t\toldref.buf + 11);\n \t\telse\n \t\t\twarning(_(\"Renamed a misnamed branch '%s' away\"),\n-- \n2.15.0.291.g0d8980c5d\n\n"},{"id":"332807","messageId":"20171118172648.17918-5-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171118172648.17918-1-kaartic.sivaraam@gmail.com","subject":"[PATCH 4/4] builtin/branch: strip refs/heads/ using skip_prefix","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-18T17:26:48Z","receivedAt":"2017-11-18T17:28:15Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Instead of hard-coding the offset strlen(\"refs/heads/\") to skip\nthe prefix \"refs/heads/\" use the skip_prefix() function which\nis more communicative and verifies that the string actually\nstarts with that prefix.\n\nThough we don't check for the result of verification here as\nit's (almost) always the case that the string does start\nwith \"refs/heads\", it's just better to avoid hard-coding and\nbe more communicative.\n\nSigned-off-by: Kaartic Sivaraam \n---\n builtin/branch.c | 16 +++++++++++-----\n 1 file changed, 11 insertions(+), 5 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex ca9d8abd0..8c546a958 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -462,6 +462,8 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n {\n \tstruct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n \tstruct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n+\tconst char *prefix_free_oldref = NULL;\n+\tconst char *prefix_free_newref = NULL;\n \tint recovery = 0;\n \tint clobber_head_ok;\n \n@@ -493,13 +495,17 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \n+\t/* At this point it should be safe to believe that the refs have the\n+\t prefix \"refs/heads\" */\n+\tskip_prefix(oldref.buf, \"refs/heads/\", &prefix_free_oldref);\n+\tskip_prefix(newref.buf, \"refs/heads/\", &prefix_free_newref);\n+\n \tif (copy)\n \t\tstrbuf_addf(&logmsg, \"Branch: copied %s to %s\",\n \t\t\t oldref.buf, newref.buf);\n \telse\n \t\tstrbuf_addf(&logmsg, \"Branch: renamed %s to %s\",\n \t\t\t oldref.buf, newref.buf);\n-\n \tif (!copy && rename_ref(oldref.buf, newref.buf, logmsg.buf))\n \t\tdie(_(\"Branch rename failed\"));\n \tif (copy && copy_existing_ref(oldref.buf, newref.buf, logmsg.buf))\n@@ -508,10 +514,10 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \tif (recovery) {\n \t\tif (copy)\n \t\t\twarning(_(\"Created a copy of a misnamed branch '%s'\"),\n-\t\t\t\toldref.buf + 11);\n+\t\t\t\tprefix_free_oldref);\n \t\telse\n \t\t\twarning(_(\"Renamed a misnamed branch '%s' away\"),\n-\t\t\t\toldref.buf + 11);\n+\t\t\t\tprefix_free_oldref);\n \t}\n \n \tif (!copy &&\n@@ -520,9 +526,9 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \n \tstrbuf_release(&logmsg);\n \n-\tstrbuf_addf(&oldsection, \"branch.%s\", oldref.buf + 11);\n+\tstrbuf_addf(&oldsection, \"branch.%s\", prefix_free_oldref);\n \tstrbuf_release(&oldref);\n-\tstrbuf_addf(&newsection, \"branch.%s\", newref.buf + 11);\n+\tstrbuf_addf(&newsection, \"branch.%s\", prefix_free_newref);\n \tstrbuf_release(&newref);\n \tif (!copy && git_config_rename_section(oldsection.buf, newsection.buf) < 0)\n \t\tdie(_(\"Branch is renamed, but update of config-file failed\"));\n-- \n2.15.0.291.g0d8980c5d\n\n"},{"id":"332834","messageId":"CAPig+cRrJVhYMYfoFhSi+FOLv0X4or1-YV=M8_X10_d_Bbt3pA@mail.gmail.com","threadId":"46452","inReplyTo":"20171118172648.17918-5-kaartic.sivaraam@gmail.com","subject":"Re: [PATCH 4/4] builtin/branch: strip refs/heads/ using skip_prefix","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2017-11-19T01:04:54Z","receivedAt":"2017-11-19T01:05:01Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sat, Nov 18, 2017 at 12:26 PM, Kaartic Sivaraam\n wrote:\n> Instead of hard-coding the offset strlen(\"refs/heads/\") to skip\n> the prefix \"refs/heads/\" use the skip_prefix() function which\n> is more communicative and verifies that the string actually\n> starts with that prefix.\n>\n> Though we don't check for the result of verification here as\n> it's (almost) always the case that the string does start\n> with \"refs/heads\", it's just better to avoid hard-coding and\n> be more communicative.\n>\n> Signed-off-by: Kaartic Sivaraam \n> ---\n> diff --git a/builtin/branch.c b/builtin/branch.c\n> @@ -462,6 +462,8 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n> {\n> struct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n> struct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n> + const char *prefix_free_oldref = NULL;\n> + const char *prefix_free_newref = NULL;\n\nA bit of a mouthful. Perhaps name these 'oldname' and 'newname' or something?\n"},{"id":"332854","messageId":"a3bba8dc-0f4c-808c-9b6e-2252160a2cc1@gmail.com","threadId":"46452","inReplyTo":"CAPig+cRrJVhYMYfoFhSi+FOLv0X4or1-YV=M8_X10_d_Bbt3pA@mail.gmail.com","subject":"Re: [PATCH 4/4] builtin/branch: strip refs/heads/ using skip_prefix","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-19T17:21:59Z","receivedAt":"2017-11-19T17:22:14Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Sunday 19 November 2017 06:34 AM, Eric Sunshine wrote:\n> On Sat, Nov 18, 2017 at 12:26 PM, Kaartic Sivaraam\n> wrote:\n>> diff --git a/builtin/branch.c b/builtin/branch.c\n>> @@ -462,6 +462,8 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n>> {\n>> struct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n>> struct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n>> + const char *prefix_free_oldref = NULL;\n>> + const char *prefix_free_newref = NULL;\n> \n> A bit of a mouthful.\n> \n\nQuite possibly.\n\n\n > Perhaps name these 'oldname' and 'newname' or something?\n\nHow about the following ?\n\n1) \"interpreted_oldname\" and \"interpreted_newname\" or\n\n2) \"stripped_oldref\" and \"stripped_newref\"\n\nI couldn't come up with better names for now.\n\n\n---\nKaartic\n"},{"id":"332865","messageId":"CAPig+cRXk8LdTFKagNFJ3L3AUsA=ZAs=eiaBwBs4JDYG303vmA@mail.gmail.com","threadId":"46452","inReplyTo":"a3bba8dc-0f4c-808c-9b6e-2252160a2cc1@gmail.com","subject":"Re: [PATCH 4/4] builtin/branch: strip refs/heads/ using skip_prefix","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2017-11-19T18:06:32Z","receivedAt":"2017-11-19T18:06:38Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Nov 19, 2017 at 12:21 PM, Kaartic Sivaraam\n wrote:\n> On Sunday 19 November 2017 06:34 AM, Eric Sunshine wrote:\n>> On Sat, Nov 18, 2017 at 12:26 PM, Kaartic Sivaraam\n>> wrote:\n>>>\n>>> diff --git a/builtin/branch.c b/builtin/branch.c\n>>> @@ -462,6 +462,8 @@ static void copy_or_rename_branch(const char\n>>> *oldname, const char *newname, int\n>>> {\n>>> struct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg\n>>> = STRBUF_INIT;\n>>> struct strbuf oldsection = STRBUF_INIT, newsection =\n>>> STRBUF_INIT;\n>>> + const char *prefix_free_oldref = NULL;\n>>> + const char *prefix_free_newref = NULL;\n>>\n>> A bit of a mouthful.\n>> Perhaps name these 'oldname' and 'newname' or something?\n>\n> How about the following ?\n>\n> 1) \"interpreted_oldname\" and \"interpreted_newname\" or\n>\n> 2) \"stripped_oldref\" and \"stripped_newref\"\n>\n> I couldn't come up with better names for now.\n\nSorry, I didn't look closely enough at the context to see that\n'oldname' and 'newname' were already used as function arguments.\n\nPerhaps call them 'oldref_bare' and 'newref_bare' or something. It not\nthat important (though, shorter may be preferable). Aside from the\nnames being rather long, what I didn't mention originally (because I\nhad edited it out of my earlier response) was that having \"free\" in\nthe names made me think that the values needed to be passed to free()\nby the end of the function. It's probably not worth a re-roll,\nthough...\n"},{"id":"333768","messageId":"20171129034620.4719-1-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171118172648.17918-5-kaartic.sivaraam@gmail.com","subject":"[PATCH v4 4/4] builtin/branch: strip refs/heads/ using skip_prefix","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-29T03:46:20Z","receivedAt":"2017-11-29T03:46:47Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Instead of hard-coding the offset strlen(\"refs/heads/\") to skip\nthe prefix \"refs/heads/\" use the skip_prefix() function which\nis more communicative and verifies that the string actually\nstarts with that prefix.\n\nSigned-off-by: Kaartic Sivaraam \n---\n v2 and v3 of this patch got detached to a different thread due\n to a small mistake I made, sorry. You can find it at\n\n https://public-inbox.org/git/20171121141852.551-1-kaartic.sivaraam@gmail.com/\n\n I've brought v4 back to this thread to bring back the continuity. I guess\n this series gets stabilised with this patch.\n\n Changes in v4 from v1:\n\n - updated commit message\n\n - removed superfluous comment\n\n - updated variable names\n\n - checked for the errors pointed out by skip_prefix\n\n builtin/branch.c | 15 +++++++++++----\n 1 file changed, 11 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex ca9d8abd0..b2f5e4a0c 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -462,6 +462,8 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n {\n \tstruct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n \tstruct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n+\tconst char *interpreted_oldname = NULL;\n+\tconst char *interpreted_newname = NULL;\n \tint recovery = 0;\n \tint clobber_head_ok;\n \n@@ -493,6 +495,11 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \n+\tif (!skip_prefix(oldref.buf, \"refs/heads/\", &interpreted_oldname) ||\n+\t !skip_prefix(newref.buf, \"refs/heads/\", &interpreted_newname)) {\n+\t\tdie(\"BUG: expected prefix missing for refs\")\n+\t}\n+\n \tif (copy)\n \t\tstrbuf_addf(&logmsg, \"Branch: copied %s to %s\",\n \t\t\t oldref.buf, newref.buf);\n@@ -508,10 +515,10 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \tif (recovery) {\n \t\tif (copy)\n \t\t\twarning(_(\"Created a copy of a misnamed branch '%s'\"),\n-\t\t\t\toldref.buf + 11);\n+\t\t\t\tinterpreted_oldname);\n \t\telse\n \t\t\twarning(_(\"Renamed a misnamed branch '%s' away\"),\n-\t\t\t\toldref.buf + 11);\n+\t\t\t\tinterpreted_oldname);\n \t}\n \n \tif (!copy &&\n@@ -520,9 +527,9 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \n \tstrbuf_release(&logmsg);\n \n-\tstrbuf_addf(&oldsection, \"branch.%s\", oldref.buf + 11);\n+\tstrbuf_addf(&oldsection, \"branch.%s\", interpreted_oldname);\n \tstrbuf_release(&oldref);\n-\tstrbuf_addf(&newsection, \"branch.%s\", newref.buf + 11);\n+\tstrbuf_addf(&newsection, \"branch.%s\", interpreted_newname);\n \tstrbuf_release(&newref);\n \tif (!copy && git_config_rename_section(oldsection.buf, newsection.buf) < 0)\n \t\tdie(_(\"Branch is renamed, but update of config-file failed\"));\n-- \n2.15.0.531.g2ccb3012c\n\n"},{"id":"333901","messageId":"20171201055933.19368-1-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171129034620.4719-1-kaartic.sivaraam@gmail.com","subject":"[PATCH v5 4/4] builtin/branch: strip refs/heads/ using skip_prefix","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-12-01T05:59:33Z","receivedAt":"2017-12-01T06:03:09Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Instead of hard-coding the offset strlen(\"refs/heads/\") to skip\nthe prefix \"refs/heads/\" use the skip_prefix() function which\nis more communicative and verifies that the string actually\nstarts with that prefix.\n\nSigned-off-by: Kaartic Sivaraam \n---\nSorry, missed a ';' in v4.\n\nThe surprising thing I discovered in the TravisCI build for v4\nwas that apart from the 'Documentation' build the 'Static Analysis'\nbuild passed, with the following output,\n\n-- \n$ ci/run-static-analysis.sh\nGIT_VERSION = 2.13.1.1972.g6ced3f745\n SPATCH contrib/coccinelle/array.cocci\n SPATCH result: contrib/coccinelle/array.cocci.patch\n SPATCH contrib/coccinelle/free.cocci\n SPATCH contrib/coccinelle/object_id.cocci\n SPATCH contrib/coccinelle/qsort.cocci\n SPATCH contrib/coccinelle/strbuf.cocci\n SPATCH result: contrib/coccinelle/strbuf.cocci.patch\n SPATCH contrib/coccinelle/swap.cocci\n SPATCH contrib/coccinelle/xstrdup_or_null.cocci\n\nThe command \"ci/run-static-analysis.sh\" exited with 0.\n-- --\n\n+Cc: SZEDER\nI guess static analysis tools make an assumption that the source\ncode is syntactically valid for them to work correctly. So, I guess\nwe should at least make sure the code 'compiles' before running\nthe static analysis tool even though we don't build it completely.\nI'm not sure if it's a bad thing to run the static analysis on code\nthat isn't syntactically valid, though.\n\n\n builtin/branch.c | 15 +++++++++++----\n 1 file changed, 11 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex ca9d8abd0..196d5fe9b 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -462,6 +462,8 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n {\n \tstruct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n \tstruct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n+\tconst char *interpreted_oldname = NULL;\n+\tconst char *interpreted_newname = NULL;\n \tint recovery = 0;\n \tint clobber_head_ok;\n \n@@ -493,6 +495,11 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \n+\tif (!skip_prefix(oldref.buf, \"refs/heads/\", &interpreted_oldname) ||\n+\t !skip_prefix(newref.buf, \"refs/heads/\", &interpreted_newname)) {\n+\t\tdie(\"BUG: expected prefix missing for refs\");\n+\t}\n+\n \tif (copy)\n \t\tstrbuf_addf(&logmsg, \"Branch: copied %s to %s\",\n \t\t\t oldref.buf, newref.buf);\n@@ -508,10 +515,10 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \tif (recovery) {\n \t\tif (copy)\n \t\t\twarning(_(\"Created a copy of a misnamed branch '%s'\"),\n-\t\t\t\toldref.buf + 11);\n+\t\t\t\tinterpreted_oldname);\n \t\telse\n \t\t\twarning(_(\"Renamed a misnamed branch '%s' away\"),\n-\t\t\t\toldref.buf + 11);\n+\t\t\t\tinterpreted_oldname);\n \t}\n \n \tif (!copy &&\n@@ -520,9 +527,9 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \n \tstrbuf_release(&logmsg);\n \n-\tstrbuf_addf(&oldsection, \"branch.%s\", oldref.buf + 11);\n+\tstrbuf_addf(&oldsection, \"branch.%s\", interpreted_oldname);\n \tstrbuf_release(&oldref);\n-\tstrbuf_addf(&newsection, \"branch.%s\", newref.buf + 11);\n+\tstrbuf_addf(&newsection, \"branch.%s\", interpreted_newname);\n \tstrbuf_release(&newref);\n \tif (!copy && git_config_rename_section(oldsection.buf, newsection.buf) < 0)\n \t\tdie(_(\"Branch is renamed, but update of config-file failed\"));\n-- \n2.15.0.531.g2ccb3012c\n\n"},{"id":"334031","messageId":"CAM0VKjmy8J5VnROyv_O=iVdwn2yELUjPv=XNu6JzJ+OePWbh4w@mail.gmail.com","threadId":"46452","inReplyTo":"20171201055933.19368-1-kaartic.sivaraam@gmail.com","subject":"Re: [PATCH v5 4/4] builtin/branch: strip refs/heads/ using skip_prefix","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-12-04T04:29:15Z","receivedAt":"2017-12-04T04:29:21Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Dec 1, 2017 at 6:59 AM, Kaartic Sivaraam\n wrote:\n> Sorry, missed a ';' in v4.\n>\n> The surprising thing I discovered in the TravisCI build for v4\n> was that apart from the 'Documentation' build the 'Static Analysis'\n> build passed, with the following output,\n>\n> -- \n> $ ci/run-static-analysis.sh\n> GIT_VERSION = 2.13.1.1972.g6ced3f745\n> SPATCH contrib/coccinelle/array.cocci\n> SPATCH result: contrib/coccinelle/array.cocci.patch\n> SPATCH contrib/coccinelle/free.cocci\n> SPATCH contrib/coccinelle/object_id.cocci\n> SPATCH contrib/coccinelle/qsort.cocci\n> SPATCH contrib/coccinelle/strbuf.cocci\n> SPATCH result: contrib/coccinelle/strbuf.cocci.patch\n> SPATCH contrib/coccinelle/swap.cocci\n> SPATCH contrib/coccinelle/xstrdup_or_null.cocci\n>\n> The command \"ci/run-static-analysis.sh\" exited with 0.\n\nPerhaps Coccinelle should have errored out, or perhaps its 0 exit code\nmeans \"I didn't find any code matching any of the semantic patches that\nrequired transformation\".\n\n> I guess static analysis tools make an assumption that the source\n> code is syntactically valid for them to work correctly. So, I guess\n> we should at least make sure the code 'compiles' before running\n> the static analysis tool even though we don't build it completely.\n> I'm not sure if it's a bad thing to run the static analysis on code\n> that isn't syntactically valid, though.\n\nTravis CI already runs 6 build jobs compiling Git. And that is in\naddition to the one that you should have run yourself before even\nthinking about submitting v4 ;) That's plenty to catch errors like\nthese. And if any of those builds fail because Git can't be built or\nbecause of a test failure, then Coccinelle's success doesn't matter at\nall, because the commit is toast anyway.\n\n\nGábor\n"},{"id":"334389","messageId":"xmqqh8t2b0tw.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"CAM0VKjmy8J5VnROyv_O=iVdwn2yELUjPv=XNu6JzJ+OePWbh4w@mail.gmail.com","subject":"Re: [PATCH v5 4/4] builtin/branch: strip refs/heads/ using skip_prefix","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-12-07T23:00:27Z","receivedAt":"2017-12-07T23:00:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n> On Fri, Dec 1, 2017 at 6:59 AM, Kaartic Sivaraam\n> wrote:\n>> Sorry, missed a ';' in v4.\n>>\n>> The surprising thing I discovered in the TravisCI build for v4\n>> was that apart from the 'Documentation' build the 'Static Analysis'\n>> build passed, with the following output,\n>>\n>> -- \n>> $ ci/run-static-analysis.sh\n>> GIT_VERSION = 2.13.1.1972.g6ced3f745\n>> SPATCH contrib/coccinelle/array.cocci\n>> SPATCH result: contrib/coccinelle/array.cocci.patch\n>> SPATCH contrib/coccinelle/free.cocci\n>> SPATCH contrib/coccinelle/object_id.cocci\n>> SPATCH contrib/coccinelle/qsort.cocci\n>> SPATCH contrib/coccinelle/strbuf.cocci\n>> SPATCH result: contrib/coccinelle/strbuf.cocci.patch\n>> SPATCH contrib/coccinelle/swap.cocci\n>> SPATCH contrib/coccinelle/xstrdup_or_null.cocci\n>>\n>> The command \"ci/run-static-analysis.sh\" exited with 0.\n>\n> Perhaps Coccinelle should have errored out, or perhaps its 0 exit code\n> means \"I didn't find any code matching any of the semantic patches that\n> required transformation\".\n>\n>> I guess static analysis tools make an assumption that the source\n>> code is syntactically valid for them to work correctly. So, I guess\n>> we should at least make sure the code 'compiles' before running\n>> the static analysis tool even though we don't build it completely.\n>> I'm not sure if it's a bad thing to run the static analysis on code\n>> that isn't syntactically valid, though.\n>\n> Travis CI already runs 6 build jobs compiling Git. And that is in\n> addition to the one that you should have run yourself before even\n> thinking about submitting v4 ;) That's plenty to catch errors like\n> these. And if any of those builds fail because Git can't be built or\n> because of a test failure, then Coccinelle's success doesn't matter at\n> all, because the commit is toast anyway.\n\nSomehow this fell underneath my radar horizon. I see v4 and v5 of\n4/4 but do not seem to find 1-3/4. Is this meant to be a standalone\npatch, or am I expected to already have 1-3 that we already are\ncommitted to take?\n\nThanks.\n\n"},{"id":"334390","messageId":"xmqqd13qb079.fsf@gitster.mtv.corp.google.com","threadId":"46452","inReplyTo":"xmqqh8t2b0tw.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v5 4/4] builtin/branch: strip refs/heads/ using skip_prefix","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-12-07T23:14:02Z","receivedAt":"2017-12-07T23:14:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> SZEDER Gábor writes:\n>\n>> On Fri, Dec 1, 2017 at 6:59 AM, Kaartic Sivaraam\n>> wrote:\n>>> Sorry, missed a ';' in v4.\n>>>\n>>> The surprising thing I discovered in the TravisCI build for v4\n>>> was that apart from the 'Documentation' build the 'Static Analysis'\n>>> build passed, with the following output,\n>>>\n>>> -- \n>>> $ ci/run-static-analysis.sh\n>>> GIT_VERSION = 2.13.1.1972.g6ced3f745\n>>> SPATCH contrib/coccinelle/array.cocci\n>>> SPATCH result: contrib/coccinelle/array.cocci.patch\n>>> SPATCH contrib/coccinelle/free.cocci\n>>> SPATCH contrib/coccinelle/object_id.cocci\n>>> SPATCH contrib/coccinelle/qsort.cocci\n>>> SPATCH contrib/coccinelle/strbuf.cocci\n>>> SPATCH result: contrib/coccinelle/strbuf.cocci.patch\n>>> SPATCH contrib/coccinelle/swap.cocci\n>>> SPATCH contrib/coccinelle/xstrdup_or_null.cocci\n>>>\n>>> The command \"ci/run-static-analysis.sh\" exited with 0.\n>>\n>> Perhaps Coccinelle should have errored out, or perhaps its 0 exit code\n>> means \"I didn't find any code matching any of the semantic patches that\n>> required transformation\".\n>>\n>>> I guess static analysis tools make an assumption that the source\n>>> code is syntactically valid for them to work correctly. So, I guess\n>>> we should at least make sure the code 'compiles' before running\n>>> the static analysis tool even though we don't build it completely.\n>>> I'm not sure if it's a bad thing to run the static analysis on code\n>>> that isn't syntactically valid, though.\n>>\n>> Travis CI already runs 6 build jobs compiling Git. And that is in\n>> addition to the one that you should have run yourself before even\n>> thinking about submitting v4 ;) That's plenty to catch errors like\n>> these. And if any of those builds fail because Git can't be built or\n>> because of a test failure, then Coccinelle's success doesn't matter at\n>> all, because the commit is toast anyway.\n>\n> Somehow this fell underneath my radar horizon. I see v4 and v5 of\n> 4/4 but do not seem to find 1-3/4. Is this meant to be a standalone\n> patch, or am I expected to already have 1-3 that we already are\n> committed to take?\n\nAh, I am guessing that this would apply on top of 1-3/4 in the\nthread with <20171118172648.17918-1-kaartic.sivaraam@gmail.com>\n\nThe base of the series seems to predate 16169285 (\"Merge branch\n'jc/branch-name-sanity'\", 2017-11-28), so let me see how it looks by\napplying those three plus this one on top of 'master' before that\npoint.\n\n"},{"id":"334463","messageId":"b0d7a230-b03e-20a3-1e57-dc42b4cbdda7@gmail.com","threadId":"46452","inReplyTo":"xmqqd13qb079.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v5 4/4] builtin/branch: strip refs/heads/ using skip_prefix","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-12-08T17:39:48Z","receivedAt":"2017-12-08T17:40:12Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Friday 08 December 2017 04:44 AM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>>\n>> Somehow this fell underneath my radar horizon. I see v4 and v5 of\n>> 4/4 but do not seem to find 1-3/4. Is this meant to be a standalone\n>> patch, or am I expected to already have 1-3 that we already are\n>> committed to take?\n> \n> Ah, I am guessing that this would apply on top of 1-3/4 in the\n> thread with <20171118172648.17918-1-kaartic.sivaraam@gmail.com>\n> \n\nYou guessed right; at the right time. I was about to ask why this got \n\"out of your radar\" in reply to your recent \"What's cooking\" email :-)\n\n\n> The base of the series seems to predate 16169285 (\"Merge branch\n> 'jc/branch-name-sanity'\", 2017-11-28), so let me see how it looks by\n> applying those three plus this one on top of 'master' before that\n> point.\n> \n\nLet me know if this has terrible conflicts so that I can rebase the \nseries on top of 'master'.\n\n\nThanks,\nKaartic\n"},{"id":"341399","messageId":"20180310155416.21802-1-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20171102065407.25404-1-kaartic.sivaraam@gmail.com","subject":"[PATCH v4 0/3] give more useful error messages while renaming branch (reboot)","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2018-03-10T15:54:13Z","receivedAt":"2018-03-10T15:54:57Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"It's been a long time since the v3 of the patch. So, it's worth restating\nthe reason behind this patch.\n\nFrom v1 of this patch,\n\n In builtin/branch, the error messages weren't handled directly by the branch\n renaming function and was left to the other function. Though this avoids\n redundancy this gave unclear error messages in some cases. So, make\n builtin/branch give more useful error messages.\n\nChanges since v3:\n\n - Handled more error related to old branch name.\n\n - Incorporated changes suggested in v3 which include using ';' as a sentence\n connector instead 'and'.\n\n - Error messages use the interpreted branch names (without the (refs/heads/ part).\n\nThe unrelated cleanup patches which were in the previous versions have\nsince been submitted as a separate series and have been merged into\nthe codebase.\n\nThe first two patches are related to the topic of this patch. The 3rd one\nis a little typo fix that I noticed on the way.\n\nThis patch was based off 'master' and has been rebased to incorporate\nthe new changes to 'master'. So, it generally should apply cleanly on\n'master'. Let me know if it doesn't.\n\nThe sample input/output cases for this patch are as follows,\n\n\t$ git branch\n\t* master\n\t foo\n\t bar\n\nBefore patch,\n\n\t# Case 1: Trying to rename non-existent branch\n\t$ git branch -m hypothet no_such_branch\n\terror: refname refs/heads/hypothet not found\n\tfatal: Branch rename failed\n\n\t# Case 2: Trying to rename non-existent branch to an existing one\n\t$ git branch -m hypothet master\n\tfatal: A branch named 'master' already exists.\n\n\t# Case 3: Trying to force update current branch\n\t$ git branch -M foo master\n\tfatal: Cannot force update the current branch.\n\n\t# Case 4: Trying to force rename an in-existent branch with an invalid name\n\t$ git branch -M hypothet ?123\n\tfatal: '?123' is not a valid branch name.\n\nAfter patch,\n\n\t# Case 1: Trying to rename non-existent branch\n\t$ git branch -m hypothet no_such_branch\n\tfatal: branch 'hypothet' doesn't exist\n\n\t# Case 2: Trying to rename non-existent branch to an existing one\n\t$ git branch -m hypothet master\n\tfatal: branch 'hypothet' doesn't exist; branch 'master' already exists\n\n\t# Case 3: Trying to force update current branch\n\t$ git branch -M foo master\n\tfatal: cannot force update the current branch\n\n\t# Case 4: Trying to force rename an in-existent branch with an invalid name\n\t$ git branch -M hypothet ?123\n\tfatal: branch 'hypothet' doesn't exist; new branch name '?123' is invalid\n\n\nNote: Thanks to the strbuf API that made it possible to easily\nconstruct the composite error message strings!\n\nKaartic Sivaraam (3):\n branch: introduce dont_fail parameter for branchname validation\n builtin/branch: give more useful error messages when renaming\n t/t3200: fix a typo in a test description\n\n branch.c | 59 +++++++++++++-----------\n branch.h | 61 ++++++++++++++++++++-----\n builtin/branch.c | 111 ++++++++++++++++++++++++++++++++++++++-------\n builtin/checkout.c | 5 +-\n t/t3200-branch.sh | 2 +-\n 5 files changed, 181 insertions(+), 57 deletions(-)\n\n-- \n2.16.1.291.g4437f3f13\n\n"},{"id":"341400","messageId":"20180310155416.21802-2-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20180310155416.21802-1-kaartic.sivaraam@gmail.com","subject":"[PATCH v4 1/3] branch: introduce dont_fail parameter for branchname validation","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2018-03-10T15:54:14Z","receivedAt":"2018-03-10T15:55:03Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"This parameter allows the branchname validation functions to\noptionally return a flag specifying the reason for failure, when\nrequested. This allows the caller to know why it was about to die.\nThis allows more useful error messages to be given to the user when\ntrying to rename a branch.\n\nThe flags are specified in the form of an enum and values for success\nflags have been assigned explicitly to clearly express that certain\ncallers rely on those values and they cannot be arbitrary.\n\nOnly the logic has been added but no caller has been made to use\nit, yet. So, no functional changes.\n\nSigned-off-by: Kaartic Sivaraam \n---\n branch.c | 59 ++++++++++++++++++++++++--------------------\n branch.h | 61 +++++++++++++++++++++++++++++++++++++---------\n builtin/branch.c | 4 +--\n builtin/checkout.c | 5 ++--\n 4 files changed, 88 insertions(+), 41 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 2672054f0..0eeb8403e 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -178,41 +178,48 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)\n \treturn 0;\n }\n \n-/*\n- * Check if 'name' can be a valid name for a branch; die otherwise.\n- * Return 1 if the named branch already exists; return 0 otherwise.\n- * Fill ref with the full refname for the branch.\n- */\n-int validate_branchname(const char *name, struct strbuf *ref)\n+enum branch_validation_result validate_branchname(const char *name, struct strbuf *ref, unsigned gently)\n {\n-\tif (strbuf_check_branch_ref(ref, name))\n-\t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n+\tif (strbuf_check_branch_ref(ref, name)) {\n+\t\tif (gently)\n+\t\t\treturn VALIDATION_FATAL_INVALID_BRANCH_NAME;\n+\t\telse\n+\t\t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n+\t}\n \n-\treturn ref_exists(ref->buf);\n+\treturn ref_exists(ref->buf) ? VALIDATION_PASS_BRANCH_EXISTS : VALIDATION_PASS_BRANCH_DOESNT_EXIST;\n }\n \n-/*\n- * Check if a branch 'name' can be created as a new branch; die otherwise.\n- * 'force' can be used when it is OK for the named branch already exists.\n- * Return 1 if the named branch already exists; return 0 otherwise.\n- * Fill ref with the full refname for the branch.\n- */\n-int validate_new_branchname(const char *name, struct strbuf *ref, int force)\n+enum branch_validation_result validate_new_branchname(const char *name, struct strbuf *ref, int force, unsigned gently)\n {\n \tconst char *head;\n \n-\tif (!validate_branchname(name, ref))\n-\t\treturn 0;\n+\tif (gently) {\n+\t\tenum branch_validation_result res = validate_branchname(name, ref, 1);\n+\t\tif (res == VALIDATION_FATAL_INVALID_BRANCH_NAME || res == VALIDATION_PASS_BRANCH_DOESNT_EXIST)\n+\t\t\t\treturn res;\n+\t} else {\n+\t\tif (validate_branchname(name, ref, 0) == VALIDATION_PASS_BRANCH_DOESNT_EXIST)\n+\t\t\treturn VALIDATION_PASS_BRANCH_DOESNT_EXIST;\n+\t}\n \n-\tif (!force)\n-\t\tdie(_(\"A branch named '%s' already exists.\"),\n-\t\t ref->buf + strlen(\"refs/heads/\"));\n+\tif (!force) {\n+\t\tif (gently)\n+\t\t\treturn VALIDATION_FATAL_BRANCH_EXISTS_NO_FORCE;\n+\t\telse\n+\t\t\tdie(_(\"A branch named '%s' already exists.\"),\n+\t\t\t\tref->buf + strlen(\"refs/heads/\"));\n+\t}\n \n \thead = resolve_ref_unsafe(\"HEAD\", 0, NULL, NULL);\n-\tif (!is_bare_repository() && head && !strcmp(head, ref->buf))\n-\t\tdie(_(\"Cannot force update the current branch.\"));\n+\tif (!is_bare_repository() && head && !strcmp(head, ref->buf)) {\n+\t\tif (gently)\n+\t\t\treturn VALIDATION_FATAL_CANNOT_FORCE_UPDATE_CURRENT_BRANCH;\n+\t\telse\n+\t\t\tdie(_(\"Cannot force update the current branch.\"));\n+\t}\n \n-\treturn 1;\n+\treturn VALIDATION_WARN_BRANCH_EXISTS;\n }\n \n static int check_tracking_branch(struct remote *remote, void *cb_data)\n@@ -259,8 +266,8 @@ void create_branch(const char *name, const char *start_name,\n \t\texplicit_tracking = 1;\n \n \tif ((track == BRANCH_TRACK_OVERRIDE || clobber_head_ok)\n-\t ? validate_branchname(name, &ref)\n-\t : validate_new_branchname(name, &ref, force)) {\n+\t ? validate_branchname(name, &ref, 0)\n+\t : validate_new_branchname(name, &ref, force, 0)) {\n \t\tif (!force)\n \t\t\tdont_change_ref = 1;\n \t\telse\ndiff --git a/branch.h b/branch.h\nindex 473d0a93e..ee5f1c0e7 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -28,20 +28,59 @@ void create_branch(const char *name, const char *start_name,\n \t\t int force, int clobber_head_ok,\n \t\t int reflog, int quiet, enum branch_track track);\n \n-/*\n- * Check if 'name' can be a valid name for a branch; die otherwise.\n- * Return 1 if the named branch already exists; return 0 otherwise.\n- * Fill ref with the full refname for the branch.\n- */\n-extern int validate_branchname(const char *name, struct strbuf *ref);\n+enum branch_validation_result {\n+\t/* Flags that convey there are fatal errors */\n+\tVALIDATION_FATAL_BRANCH_EXISTS_NO_FORCE = -3,\n+\tVALIDATION_FATAL_CANNOT_FORCE_UPDATE_CURRENT_BRANCH,\n+\tVALIDATION_FATAL_INVALID_BRANCH_NAME,\n+\t/* Flags that convey there are no fatal errors */\n+\tVALIDATION_PASS_BRANCH_DOESNT_EXIST = 0,\n+\tVALIDATION_PASS_BRANCH_EXISTS = 1,\n+\tVALIDATION_WARN_BRANCH_EXISTS = 2\n+};\n \n /*\n- * Check if a branch 'name' can be created as a new branch; die otherwise.\n- * 'force' can be used when it is OK for the named branch already exists.\n- * Return 1 if the named branch already exists; return 0 otherwise.\n- * Fill ref with the full refname for the branch.\n+ * Check if 'name' can be a valid name for a branch; die otherwise.\n+ *\n+ * - name is the new branch name\n+ *\n+ * - ref is used to return the full refname for the branch\n+ *\n+ * The return values have the following meaning,\n+ *\n+ * - If 'gently' is 0, the function dies in case of a fatal error and returns\n+ * flags of 'branch_validation_result' that indicate nonfatal cases, otherwise.\n+ * The positive non-zero flag implies that the branch exists.\n+ *\n+ * - If 'gently' is 1, the function doesn't die in case of a fatal error but returns\n+ * flags of 'branch_validaton_result' that identify the fatal error. The behaviour\n+ * in case of success is same as above.\n+ *\n */\n-extern int validate_new_branchname(const char *name, struct strbuf *ref, int force);\n+extern enum branch_validation_result validate_branchname(const char *name, struct strbuf *ref, unsigned gently);\n+\n+/*\n+ * Check if a branch 'name' can be created as a new branch.\n+ *\n+ * - name is the new branch name\n+ *\n+ * - ref is used to return the full refname for the branch\n+ *\n+ * - force can be used when it is OK if the named branch already exists.\n+ * the currently checkout branch; with 'shouldnt_exist', it has no effect.\n+ *\n+ * The return values have the following meaning,\n+ *\n+ * - If 'gently' is 0, the function dies in case of a fatal error and returns\n+ * flags of 'branch_validation_result' that indicate nonfatal cases, otherwise.\n+ * The positive non-zero flag implies that the branch can be force updated.\n+ *\n+ * - If 'gently' is 1, the function doesn't die in case of a fatal error but returns\n+ * flags of 'branch_validaton_result' that identify the fatal error. The behaviour\n+ * in case of success is same as above.\n+ *\n+ */\n+extern enum branch_validation_result validate_new_branchname(const char *name, struct strbuf *ref, int force, unsigned gently);\n \n /*\n * Remove information about the state of working on the current\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 8dcc2ed05..5412aa78f 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -489,9 +489,9 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \t * cause the worktree to become inconsistent with HEAD, so allow it.\n \t */\n \tif (!strcmp(oldname, newname))\n-\t\tvalidate_branchname(newname, &newref);\n+\t\tvalidate_branchname(newname, &newref, 0);\n \telse\n-\t\tvalidate_new_branchname(newname, &newref, force);\n+\t\tvalidate_new_branchname(newname, &newref, force, 0);\n \n \treject_rebase_or_bisect_branch(oldref.buf);\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex 8f4dfb104..c16455ff0 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1243,10 +1243,11 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\tstruct strbuf buf = STRBUF_INIT;\n \n \t\tif (opts.new_branch_force)\n-\t\t\topts.branch_exists = validate_branchname(opts.new_branch, &buf);\n+\t\t\topts.branch_exists = validate_branchname(opts.new_branch, &buf, 0);\n \t\telse\n \t\t\topts.branch_exists =\n-\t\t\t\tvalidate_new_branchname(opts.new_branch, &buf, 0);\n+\t\t\t\tvalidate_new_branchname(opts.new_branch, &buf, 0, 0);\n+\n \t\tstrbuf_release(&buf);\n \t}\n \n-- \n2.16.1.291.g4437f3f13\n\n"},{"id":"341401","messageId":"20180310155416.21802-3-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20180310155416.21802-1-kaartic.sivaraam@gmail.com","subject":"[PATCH v4 2/3] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2018-03-10T15:54:15Z","receivedAt":"2018-03-10T15:55:10Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"When trying to rename an \"inexistent\" branch name to a branch name\nthat \"already exists\" the rename failed stating that the new branch\nname exists rather than stating that the branch trying to be renamed\ndoesn't exist.\n\n $ git branch -m tset master\n fatal: A branch named 'master' already exists.\n\nIt's conventional to report that 'tset' doesn't exist rather than\nreporting that 'master' exists, the same way the 'mv' command does.\n\n (hypothetical)\n $ git branch -m tset master\n fatal: branch 'tset' doesn't exist.\n\nThat has the problem that the error about an existing branch is shown\nonly after the user corrects the error about inexistent branch.\n\n $ git branch -m test master\n fatal: A branch named 'master' already exists.\n\nThis isn't useful either because the user would have corrected this\nerror in a single go if he had been told this alongside the first\nerror. So, give more useful error messages by giving errors about old\nbranch name and new branch name at the same time. This is possible as\nthe branch name validation functions now return the reason they were\nabout to die, when requested.\n\n $ git branch -m tset master\n fatal: branch 'tset' doesn't exist; branch 'master' already exists\n\nSigned-off-by: Kaartic Sivaraam \n---\n builtin/branch.c | 111 +++++++++++++++++++++++++++++++++++++++--------\n 1 file changed, 94 insertions(+), 17 deletions(-)\n\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 5412aa78f..ab78a7f45 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -55,6 +55,13 @@ enum color_branch {\n \tBRANCH_COLOR_UPSTREAM = 5\n };\n \n+enum old_branch_validation_result {\n+\tVALIDATION_1_FATAL_OLD_BRANCH_DOESNT_EXIST = -2,\n+\tVALIDATION_1_FATAL_INVALID_OLD_BRANCH_NAME = -1,\n+\tVALIDATION_1_PASS_OLD_BRANCH_EXISTS = 0,\n+\tVALIDATION_1_WARN_BAD_OLD_BRANCH_NAME = 1\n+};\n+\n static struct string_list output = STRING_LIST_INIT_DUP;\n static unsigned int colopts;\n \n@@ -458,13 +465,86 @@ static void reject_rebase_or_bisect_branch(const char *target)\n \tfree_worktrees(worktrees);\n }\n \n+static void get_error_msg(struct strbuf* error_msg,\n+\t\t\t const char* oldname, enum old_branch_validation_result old_branch_name_res,\n+\t\t\t const char* newname, enum branch_validation_result new_branch_name_res)\n+{\n+\tconst char* connector_string = \"; \";\n+\tunsigned append_connector = 0;\n+\n+\tswitch (old_branch_name_res) {\n+\tcase VALIDATION_1_FATAL_INVALID_OLD_BRANCH_NAME:\n+\t\tstrbuf_addf(error_msg,\n+\t\t\t _(\"old branch name '%s' is invalid\"), oldname);\n+\t\tappend_connector = 1;\n+\t\tbreak;\n+\tcase VALIDATION_1_FATAL_OLD_BRANCH_DOESNT_EXIST:\n+\t\tstrbuf_addf(error_msg,\n+\t\t\t _(\"branch '%s' doesn't exist\"), oldname);\n+\t\tappend_connector = 1;\n+\t\tbreak;\n+\n+\t/* not necessary to handle nonfatal cases */\n+\tcase VALIDATION_1_PASS_OLD_BRANCH_EXISTS:\n+\tcase VALIDATION_1_WARN_BAD_OLD_BRANCH_NAME:\n+\t\tbreak;\n+\t}\n+\n+\tswitch (new_branch_name_res) {\n+\tcase VALIDATION_FATAL_BRANCH_EXISTS_NO_FORCE:\n+\t\tstrbuf_addf(error_msg, \"%s\",\n+\t\t\t (append_connector) ? connector_string : \"\");\n+\t\tstrbuf_addf(error_msg,\n+\t\t\t _(\"branch '%s' already exists\"), newname);\n+\t\tbreak;\n+\tcase VALIDATION_FATAL_CANNOT_FORCE_UPDATE_CURRENT_BRANCH:\n+\t\tstrbuf_addf(error_msg, \"%s\",\n+\t\t\t (append_connector) ? connector_string : \"\");\n+\t\tstrbuf_addstr(error_msg,\n+\t\t\t\t_(\"cannot force update the current branch\"));\n+\t\tbreak;\n+\tcase VALIDATION_FATAL_INVALID_BRANCH_NAME:\n+\t\tstrbuf_addf(error_msg, \"%s\",\n+\t\t\t (append_connector) ? connector_string : \"\");\n+\t\tstrbuf_addf(error_msg,\n+\t\t\t _(\"new branch name '%s' is invalid\"), newname);\n+\t\tbreak;\n+\n+\t/* not necessary to handle nonfatal cases */\n+\tcase VALIDATION_PASS_BRANCH_DOESNT_EXIST:\n+\tcase VALIDATION_PASS_BRANCH_EXISTS:\n+\tcase VALIDATION_WARN_BRANCH_EXISTS:\n+\t\tbreak;\n+\t}\n+}\n+\n+/* Validate the old branch name and return the result */\n+static enum old_branch_validation_result validate_old_branchname (const char* name, struct strbuf *oldref) {\n+\tint bad_ref = strbuf_check_branch_ref(oldref, name);\n+\tint branch_exists = ref_exists(oldref->buf);\n+\n+\tif (bad_ref) {\n+\t\tif(branch_exists)\n+\t\t\treturn VALIDATION_1_WARN_BAD_OLD_BRANCH_NAME;\n+\t\telse\n+\t\t\treturn VALIDATION_1_FATAL_INVALID_OLD_BRANCH_NAME;\n+\t}\n+\n+\tif (branch_exists)\n+\t\treturn VALIDATION_1_PASS_OLD_BRANCH_EXISTS;\n+\telse\n+\t\treturn VALIDATION_1_FATAL_OLD_BRANCH_DOESNT_EXIST;\n+}\n+\n static void copy_or_rename_branch(const char *oldname, const char *newname, int copy, int force)\n {\n \tstruct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n \tstruct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;\n \tconst char *interpreted_oldname = NULL;\n \tconst char *interpreted_newname = NULL;\n-\tint recovery = 0;\n+\tstruct strbuf error_msg = STRBUF_INIT, empty = STRBUF_INIT;\n+\tenum branch_validation_result new_branch_name_res;\n+\tenum old_branch_validation_result old_branch_name_res;\n \n \tif (!oldname) {\n \t\tif (copy)\n@@ -473,33 +553,28 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \t\t\tdie(_(\"cannot rename the current branch while not on any.\"));\n \t}\n \n-\tif (strbuf_check_branch_ref(&oldref, oldname)) {\n-\t\t/*\n-\t\t * Bad name --- this could be an attempt to rename a\n-\t\t * ref that we used to allow to be created by accident.\n-\t\t */\n-\t\tif (ref_exists(oldref.buf))\n-\t\t\trecovery = 1;\n-\t\telse\n-\t\t\tdie(_(\"Invalid branch name: '%s'\"), oldname);\n-\t}\n-\n+\told_branch_name_res = validate_old_branchname(oldname, &oldref);\n \t/*\n \t * A command like \"git branch -M currentbranch currentbranch\" cannot\n \t * cause the worktree to become inconsistent with HEAD, so allow it.\n \t */\n \tif (!strcmp(oldname, newname))\n-\t\tvalidate_branchname(newname, &newref, 0);\n+\t\tnew_branch_name_res = validate_branchname(newname, &newref, 1);\n \telse\n-\t\tvalidate_new_branchname(newname, &newref, force, 0);\n-\n-\treject_rebase_or_bisect_branch(oldref.buf);\n+\t\tnew_branch_name_res = validate_new_branchname(newname, &newref, force, 1);\n \n \tif (!skip_prefix(oldref.buf, \"refs/heads/\", &interpreted_oldname) ||\n \t !skip_prefix(newref.buf, \"refs/heads/\", &interpreted_newname)) {\n \t\tdie(\"BUG: expected prefix missing for refs\");\n \t}\n \n+\tget_error_msg(&error_msg, interpreted_oldname, old_branch_name_res,\n+\t\t\t\t interpreted_newname, new_branch_name_res);\n+\tif (strbuf_cmp(&error_msg, &empty))\n+\t\tdie(\"%s\", error_msg.buf);\n+\n+\treject_rebase_or_bisect_branch(oldref.buf);\n+\n \tif (copy)\n \t\tstrbuf_addf(&logmsg, \"Branch: copied %s to %s\",\n \t\t\t oldref.buf, newref.buf);\n@@ -512,7 +587,7 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \tif (copy && copy_existing_ref(oldref.buf, newref.buf, logmsg.buf))\n \t\tdie(_(\"Branch copy failed\"));\n \n-\tif (recovery) {\n+\tif (old_branch_name_res == VALIDATION_1_WARN_BAD_OLD_BRANCH_NAME) {\n \t\tif (copy)\n \t\t\twarning(_(\"Created a copy of a misnamed branch '%s'\"),\n \t\t\t\tinterpreted_oldname);\n@@ -537,6 +612,8 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int\n \t\tdie(_(\"Branch is copied, but update of config-file failed\"));\n \tstrbuf_release(&oldsection);\n \tstrbuf_release(&newsection);\n+\tstrbuf_release(&error_msg);\n+\tstrbuf_release(&empty);\n }\n \n static GIT_PATH_FUNC(edit_description, \"EDIT_DESCRIPTION\")\n-- \n2.16.1.291.g4437f3f13\n\n"},{"id":"341402","messageId":"20180310155416.21802-4-kaartic.sivaraam@gmail.com","threadId":"46452","inReplyTo":"20180310155416.21802-1-kaartic.sivaraam@gmail.com","subject":"[PATCH v4 3/3] t/t3200: fix a typo in a test description","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2018-03-10T15:54:16Z","receivedAt":"2018-03-10T15:55:15Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Signed-off-by: Kaartic Sivaraam \n---\n t/t3200-branch.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex 503a88d02..6c0b7ea4a 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -528,7 +528,7 @@ test_expect_success 'git branch -c -f o/q o/p should work when o/p exists' '\n \tgit branch -c -f o/q o/p\n '\n \n-test_expect_success 'git branch -c qq rr/qq should fail when r exists' '\n+test_expect_success 'git branch -c qq rr/qq should fail when rr exists' '\n \tgit branch qq &&\n \tgit branch rr &&\n \ttest_must_fail git branch -c qq rr/qq\n-- \n2.16.1.291.g4437f3f13\n\n"},{"id":"341827","messageId":"xmqqpo453x0k.fsf@gitster-ct.c.googlers.com","threadId":"46452","inReplyTo":"20180310155416.21802-2-kaartic.sivaraam@gmail.com","subject":"Re: [PATCH v4 1/3] branch: introduce dont_fail parameter for branchname validation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-15T20:27:07Z","receivedAt":"2018-03-15T20:27:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> This parameter allows the branchname validation functions to\n> optionally return a flag specifying the reason for failure, when\n> requested. This allows the caller to know why it was about to die.\n> This allows more useful error messages to be given to the user when\n> trying to rename a branch.\n>\n> The flags are specified in the form of an enum and values for success\n> flags have been assigned explicitly to clearly express that certain\n> callers rely on those values and they cannot be arbitrary.\n>\n> Only the logic has been added but no caller has been made to use\n> it, yet. So, no functional changes.\n>\n> Signed-off-by: Kaartic Sivaraam \n> ---\n\nSo... I am not finding dont_fail that was mentioned on the title\nanywhere else in the patch. Such lack of attention to detail is\na bit off-putting.\n\nThe change itself overall looks OK. One minor thing that made me\nwonder was this bit:\n\n> +enum branch_validation_result {\n> +\t/* Flags that convey there are fatal errors */\n> +\tVALIDATION_FATAL_BRANCH_EXISTS_NO_FORCE = -3,\n> +\tVALIDATION_FATAL_CANNOT_FORCE_UPDATE_CURRENT_BRANCH,\n> +\tVALIDATION_FATAL_INVALID_BRANCH_NAME,\n> +\t/* Flags that convey there are no fatal errors */\n> +\tVALIDATION_PASS_BRANCH_DOESNT_EXIST = 0,\n> +\tVALIDATION_PASS_BRANCH_EXISTS = 1,\n> +\tVALIDATION_WARN_BRANCH_EXISTS = 2\n> +};\n\nwhere adding new error types will force us to touch _two_ lines\n(i.e. either you add a new error before NO_FORCE with value -4 and\nthen remove the \"= -3\" from NO_FORCE, or you add a new error after\nINVALID, and update NO_FORCE to -4), which can easily be screwed up\nby a careless developer. The current code is not wrong per-se, but\nI wonder if it can be made less error prone.\n\n"},{"id":"341828","messageId":"xmqqlget3wqa.fsf@gitster-ct.c.googlers.com","threadId":"46452","inReplyTo":"20180310155416.21802-3-kaartic.sivaraam@gmail.com","subject":"Re: [PATCH v4 2/3] builtin/branch: give more useful error messages when renaming","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-15T20:33:17Z","receivedAt":"2018-03-15T20:33:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> +static void get_error_msg(struct strbuf* error_msg,\n> +\t\t\t const char* oldname, enum old_branch_validation_result old_branch_name_res,\n> +\t\t\t const char* newname, enum branch_validation_result new_branch_name_res)\n> +{\n> +\tconst char* connector_string = \"; \";\n> +\tunsigned append_connector = 0;\n> +\n> +\tswitch (old_branch_name_res) {\n> +\tcase VALIDATION_1_FATAL_INVALID_OLD_BRANCH_NAME:\n> +\t\tstrbuf_addf(error_msg,\n> +\t\t\t _(\"old branch name '%s' is invalid\"), oldname);\n> +\t\tappend_connector = 1;\n> +\t\tbreak;\n> +\tcase VALIDATION_1_FATAL_OLD_BRANCH_DOESNT_EXIST:\n> +\t\tstrbuf_addf(error_msg,\n> +\t\t\t _(\"branch '%s' doesn't exist\"), oldname);\n> +\t\tappend_connector = 1;\n> +\t\tbreak;\n> +\n> +\t/* not necessary to handle nonfatal cases */\n> +\tcase VALIDATION_1_PASS_OLD_BRANCH_EXISTS:\n> +\tcase VALIDATION_1_WARN_BAD_OLD_BRANCH_NAME:\n> +\t\tbreak;\n> +\t}\n> +\n> +\tswitch (new_branch_name_res) {\n> +\tcase VALIDATION_FATAL_BRANCH_EXISTS_NO_FORCE:\n> +\t\tstrbuf_addf(error_msg, \"%s\",\n> +\t\t\t (append_connector) ? connector_string : \"\");\n> +\t\tstrbuf_addf(error_msg,\n> +\t\t\t _(\"branch '%s' already exists\"), newname);\n> +\t\tbreak;\n> +\tcase VALIDATION_FATAL_CANNOT_FORCE_UPDATE_CURRENT_BRANCH:\n> +\t\tstrbuf_addf(error_msg, \"%s\",\n> +\t\t\t (append_connector) ? connector_string : \"\");\n> +\t\tstrbuf_addstr(error_msg,\n> +\t\t\t\t_(\"cannot force update the current branch\"));\n> +\t\tbreak;\n> +\tcase VALIDATION_FATAL_INVALID_BRANCH_NAME:\n> +\t\tstrbuf_addf(error_msg, \"%s\",\n> +\t\t\t (append_connector) ? connector_string : \"\");\n> +\t\tstrbuf_addf(error_msg,\n> +\t\t\t _(\"new branch name '%s' is invalid\"), newname);\n> +\t\tbreak;\n> +\n> +\t/* not necessary to handle nonfatal cases */\n> +\tcase VALIDATION_PASS_BRANCH_DOESNT_EXIST:\n> +\tcase VALIDATION_PASS_BRANCH_EXISTS:\n> +\tcase VALIDATION_WARN_BRANCH_EXISTS:\n> +\t\tbreak;\n> +\t}\n> +}\n\nQuite honestly, I am not sure if this amount of new code that\nresults in sentence lego is really worth it. Is it so wrong for\n\"branch -m tset master\" to complain that master already exists so no\nbranch can be renamed to it?\n"},{"id":"341830","messageId":"xmqqh8ph3wc7.fsf@gitster-ct.c.googlers.com","threadId":"46452","inReplyTo":"20180310155416.21802-4-kaartic.sivaraam@gmail.com","subject":"Re: [PATCH v4 3/3] t/t3200: fix a typo in a test description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-15T20:41:44Z","receivedAt":"2018-03-15T20:41:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> Signed-off-by: Kaartic Sivaraam \n> ---\n> t/t3200-branch.sh | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n\nThanks. It is very nice to see unrelated issues nearby found while\nworking on something else. Will queue.\n\n>\n> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\n> index 503a88d02..6c0b7ea4a 100755\n> --- a/t/t3200-branch.sh\n> +++ b/t/t3200-branch.sh\n> @@ -528,7 +528,7 @@ test_expect_success 'git branch -c -f o/q o/p should work when o/p exists' '\n> \tgit branch -c -f o/q o/p\n> '\n> \n> -test_expect_success 'git branch -c qq rr/qq should fail when r exists' '\n> +test_expect_success 'git branch -c qq rr/qq should fail when rr exists' '\n> \tgit branch qq &&\n> \tgit branch rr &&\n> \ttest_must_fail git branch -c qq rr/qq\n"},{"id":"341887","messageId":"fa87ddd0-f034-498e-c112-4393bfa0d96d@gmail.com","threadId":"46452","inReplyTo":"xmqqpo453x0k.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v4 1/3] branch: introduce dont_fail parameter for branchname validation","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2018-03-16T18:12:44Z","receivedAt":"2018-03-16T18:12:55Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Friday 16 March 2018 01:57 AM, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n> \n> So... I am not finding dont_fail that was mentioned on the title\n> anywhere else in the patch. Such lack of attention to detail is\n> a bit off-putting.\n> \n\nI'm absolutely sorry x-<\n\nI should have forgotten to update the commit subject during one of the\nold rebases in which I renamed the parameter from 'dont_fail' to 'gently'.\n\nI shouldn't have assumed that the commit messages of the old series held\nin the reboot too. I should have re-read them \"completely\" and double\nchecked it. :-(\n\n\n>> +enum branch_validation_result {\n>> +\t/* Flags that convey there are fatal errors */\n>> +\tVALIDATION_FATAL_BRANCH_EXISTS_NO_FORCE = -3,\n>> +\tVALIDATION_FATAL_CANNOT_FORCE_UPDATE_CURRENT_BRANCH,\n>> +\tVALIDATION_FATAL_INVALID_BRANCH_NAME,\n>> +\t/* Flags that convey there are no fatal errors */\n>> +\tVALIDATION_PASS_BRANCH_DOESNT_EXIST = 0,\n>> +\tVALIDATION_PASS_BRANCH_EXISTS = 1,\n>> +\tVALIDATION_WARN_BRANCH_EXISTS = 2\n>> +};\n> \n> where adding new error types will force us to touch _two_ lines\n> (i.e. either you add a new error before NO_FORCE with value -4 and\n> then remove the \"= -3\" from NO_FORCE, or you add a new error after\n> INVALID, and update NO_FORCE to -4), which can easily be screwed up\n> by a careless developer. The current code is not wrong per-se, but\n> I wonder if it can be made less error prone.\n> \n\nAt the top of my head I could think of 2 ways to get around this,\n\n\t- Assigning the actual value to every single entry in the enum.\n\n\t This should solve the issue as a any new entry that would be\n\t added is expected to go \"with a value\". The compiler would\n\t warn you in the case of duplicate values. The drawback is: it\n\t might be a little restrictive and a little ugly. It would also\n\t likely cause maintenance issues if the number of values in the\n\t enum get bigger.\n\n\t (Of course this doesn't hold if, the careless programmer\n\t shatters \"consistency\" and adds an entry without a value to\n\t the enum and that change gets merged into the codebase ;-) )\n\n\t- Using non-negative values for both errors and non-errors.\n\n\t This might make it hard to distinguish errors from non-errors\n\t but this would avoid errors completely without much issues,\n\t otherwise.\n\nI might prefer the former as I find the possibility of the requirement\nto distinguish the errors from non-errors to be high when compared with\nthe possibility of the requirement to add more new entries to the enum.\n\nAny other ideas/suggestions ?\n\n-- \n\nKaartic\n\nQUOTE:\n\n“The most valuable person on any team is the person who makes everyone\nelse on the team more valuable, not the person who knows the most.”\n\n - Joel Spolsky\n\n"},{"id":"342825","messageId":"3d5aa4f7-de4a-15d4-9987-13524dc40c59@gmail.com","threadId":"46452","inReplyTo":"xmqqlget3wqa.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v4 2/3] builtin/branch: give more useful error messages when renaming","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2018-03-24T17:09:48Z","receivedAt":"2018-03-24T17:10:08Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Friday 16 March 2018 02:03 AM, Junio C Hamano wrote:\n> Quite honestly, I am not sure if this amount of new code that\n> results in sentence lego is really worth it.\n\nSpeaking specifically about the new code for the sentence lego: I\ncurrently lack knowledge of a better way to achieve the same outcome the\nnew code does. Let me know if there is a better way.\n\n\n> Is it so wrong for\n> \"branch -m tset master\" to complain that master already exists so no\n> branch can be renamed to it?\n>\n\nSpeaking in general about the patch itself: though I still find the fact\nthat \"the error about an inexistent source branch seconds the error\nabout an existing destination branch\" to be a little unintuitive, I\nactually went on to reboot this after a long time as this also seems to\nbring consistency in the error messages related to moving a branch. It\nseems that the commit message requires an update as it currently seems\nto be misleading as it currently doesn't specify the motivation completely.\n\nThat said, I won't be against dropping the patch if it seems to be\nadding less value at the cost of more code.\n\n-- \nKaartic\n\n"}]}