{"thread":{"id":"28138","subject":"[PATCH] Disallow creating ambiguous branch names by default","startedAt":"2011-08-17T08:21:38Z","lastAt":"2011-08-19T21:52:15Z","messageCount":10,"participants":["Conrad Irwin","Junio C Hamano","Vijay Lakshminarayanan","Stephen Bash"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"173664","messageId":"1313569298-3879-1-git-send-email-conrad.irwin@gmail.com","threadId":"28138","inReplyTo":null,"subject":"[PATCH] Disallow creating ambiguous branch names by default","fromName":"Conrad Irwin","fromEmail":"conrad.irwin@gmail.com","sentAt":"2011-08-17T08:21:38Z","receivedAt":"2011-08-17T08:21:38Z","isPatch":true,"sender":{"key":"conrad.irwin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94272?v=4"},"body":"Before this change, it was comparatively easy to create a confusingly\nnamed branch (like \"origin/master\" or \"tag.1\"). The former case is\nparticularly biting to newcomers, who suddenly find themselves needing\nto handle nuances of the refs namespaces. The latter is something you're\nnot likely to want to do, the tag will take precedence when the name is\nresolved meaning that your branch will be hard to use.\n\nIn both cases, git commands would omit a warning about \"ambiguous refs\"\nif they noticed that this had occurred, however it feels nicer to help\nusers avoid getting into that situation to start with!\n\nAfter this patch, git branch , git checkout -b and git branch\n-m bar will all fail if is already a commit-ish; this\nsafety-net can be removed by passing the -f, -B or -M flags.\n\nSigned-off-by: Conrad Irwin \n\n---\n\nI considered adding a separate configuration variable to disable this\ncheck permanently, but I couldn't find a convincing use-case. Perhaps\nthe closest is in `git branch $(git describe)` as a quick way to\nbookmark a commit; but it seems like creating a tag might be a more\nsensible option in that case. Would anyone want such a flag?\n\nConrad\n\n Documentation/git-branch.txt | 5 +++--\n branch.c | 2 ++\n builtin/branch.c | 3 +++\n t/t2018-checkout-branch.sh | 16 ++++++++++++++--\n t/t3200-branch.sh | 33 +++++++++++++++++++++++++++++++++\n t/t6300-for-each-ref.sh | 2 +-\n t/t7201-co.sh | 4 ++--\n 7 files changed, 58 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex c50f189..415eae3 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -80,8 +80,9 @@ OPTIONS\n \n -f::\n --force::\n-\tReset to if exists\n-\talready. Without `-f` 'git branch' refuses to change an existing branch.\n+\tCreate the branch even when it might be confusing to do so (for\n+\texample a tag with that name already exists). If a branch with\n+\tthe same name already exists, it will be reset to .\n \n -m::\n \tMove/rename a branch and the corresponding reflog.\ndiff --git a/branch.c b/branch.c\nindex c0c865a..f26154e 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -162,6 +162,8 @@ void create_branch(const char *head,\n \t\telse if (!is_bare_repository() && head && !strcmp(head, name))\n \t\t\tdie(\"Cannot force update the current branch.\");\n \t\tforcing = 1;\n+\t} else if (!force && !get_sha1(name, sha1)) {\n+\t\tdie(\"A branch named '%s' would be ambiguous.\", name);\n \t}\n \n \treal_ref = NULL;\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 3142daa..6af1718 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -572,6 +572,9 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \tif (resolve_ref(newref.buf, sha1, 1, NULL) && !force)\n \t\tdie(_(\"A branch named '%s' already exists.\"), newref.buf + 11);\n \n+\tif (!get_sha1(newname, sha1) && !force)\n+\t\tdie(_(\"A branch named '%s' would be ambiguous.\"), newname);\n+\n \tstrbuf_addf(&logmsg, \"Branch: renamed %s to %s\",\n \t\t oldref.buf, newref.buf);\n \ndiff --git a/t/t2018-checkout-branch.sh b/t/t2018-checkout-branch.sh\nindex a42e039..26cc066 100755\n--- a/t/t2018-checkout-branch.sh\n+++ b/t/t2018-checkout-branch.sh\n@@ -169,15 +169,27 @@ test_expect_success 'checkout -f -B to an existing branch with mergeable changes\n \ttest_must_fail test_dirty_mergeable\n '\n \n-test_expect_success 'checkout -b ' '\n+test_expect_success 'checkout -B ' '\n \tgit tag -f -m \"First commit\" initial initial &&\n \tgit checkout -f change1 &&\n \tname=$(git describe) &&\n-\tgit checkout -b $name &&\n+\tgit checkout -B $name &&\n \tgit diff --exit-code change1 &&\n \techo \"refs/heads/$name\" >expect &&\n \tgit symbolic-ref HEAD >actual &&\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'checkout -b fails' '\n+\tgit tag -f -m \"First commit\" initial initial &&\n+\tgit checkout -f change1 &&\n+\ttest_must_fail git checkout -b initial\n+'\n+\n+test_expect_success 'checkout -B fails' '\n+\tgit tag -f -m \"First commit\" initial initial &&\n+\tgit checkout -f change1 &&\n+\tgit checkout -B initial\n+'\n+\n test_done\ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex 9e69c8c..f3f4542 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -230,6 +230,39 @@ test_expect_success \\\n 'git tag foobar &&\n test_must_fail git branch --track my11 foobar'\n \n+test_expect_success 'creating a branch called HEAD fails' '\n+ test_must_fail git branch HEAD\n+'\n+\n+test_expect_success 'creating a branch with an ambiguous name fails' '\n+ git tag t/g &&\n+ test_must_fail git branch t/g &&\n+ git tag -d t/g\n+'\n+\n+test_expect_success 'creating a branch with an ambigious name with -f' '\n+ git tag t/g &&\n+ git branch -f t/g &&\n+ git branch -d t/g &&\n+ git tag -d t/g\n+'\n+\n+test_expect_success 'moving a branch to an ambiguous name with -m fails' '\n+ git tag t/g &&\n+ git branch bar &&\n+ test_must_fail git branch -m bar t/g &&\n+ git branch -d bar &&\n+ git tag -d t/g\n+'\n+\n+test_expect_success 'moving a branch to an ambiguous name with -M' '\n+ git tag t/g &&\n+ git branch b/h &&\n+ git branch -M b/h t/g &&\n+ git branch -d t/g &&\n+ git tag -d t/g\n+'\n+\n # Keep this test last, as it changes the current branch\n cat >expect < 1117150200 +0000\tbranch: Created from master\ndiff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh\nindex 7dc8a51..37f0394 100755\n--- a/t/t6300-for-each-ref.sh\n+++ b/t/t6300-for-each-ref.sh\n@@ -344,7 +344,7 @@ EOF\n test_expect_success 'Check ambiguous head and tag refs II (loose)' '\n \tgit checkout master &&\n \tgit tag ambiguous testtag^0 &&\n-\tgit branch ambiguous testtag^0 &&\n+\tgit branch -f ambiguous testtag^0 &&\n \tgit for-each-ref --format \"%(refname:short)\" refs/heads/ambiguous refs/tags/ambiguous >actual &&\n \ttest_cmp expected actual\n '\ndiff --git a/t/t7201-co.sh b/t/t7201-co.sh\nindex 07fb53a..a488c5b 100755\n--- a/t/t7201-co.sh\n+++ b/t/t7201-co.sh\n@@ -311,7 +311,7 @@ test_expect_success 'checkout to detach HEAD with HEAD^0' '\n test_expect_success 'checkout with ambiguous tag/branch names' '\n \n \tgit tag both side &&\n-\tgit branch both master &&\n+\tgit branch -f both master &&\n \tgit reset --hard &&\n \tgit checkout master &&\n \n@@ -330,7 +330,7 @@ test_expect_success 'checkout with ambiguous tag/branch names' '\n \tgit checkout master &&\n \n \tgit tag frotz side &&\n-\tgit branch frotz master &&\n+\tgit branch -f frotz master &&\n \tgit reset --hard &&\n \tgit checkout master &&\n \n-- \n1.7.6.448.gc60f1\n"},{"id":"173684","messageId":"7vhb5fev8a.fsf@alter.siamese.dyndns.org","threadId":"28138","inReplyTo":"1313569298-3879-1-git-send-email-conrad.irwin@gmail.com","subject":"Re: [PATCH] Disallow creating ambiguous branch names by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-17T18:41:41Z","receivedAt":"2011-08-17T18:41:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Conrad Irwin writes:\n\n> Before this change, it was comparatively easy to create a confusingly\n\nDrop everything before the \", \".\n\n> named branch (like \"origin/master\" or \"tag.1\"). The former case is\n> particularly biting to newcomers, who suddenly find themselves needing\n> to handle nuances of the refs namespaces.\n\nIf you start forbidding certain names, newcomers will need to be exposed\nthe same nuances to understand why what they wanted to do is not allowed,\nso that is not an argument.\n\nMy preferences (take them as \"the ground rules\" if you want) are:\n\n - We don't disallow what we have long allowed, without a good reason;\n - We make sure new people will get a warning with useful advice.\n\nI would be happy to see the end result that warns when the end user\ncreates a branch (or a tag) that is ambiguous _when_ it is created (not\n\"much later, when we noticed there are ambiguous refs\"), and offers an\nadvice message to use \"branch -m\" to rename it away (control the message\nwith a new \"advice.*\" configuration and unless explicitly declined with\nit, always give the advice).\n\n> In both cases, git commands would omit a warning about \"ambiguous refs\"\n> if they noticed that this had occurred,\n\nAssuming that you meant s/omit/emit/, I do agree that what we do right now\nis suboptimal. I just tried these two:\n\n\t$ git branch v1.0.0\n $ git checkout v1.0.0\n warning: refname 'v1.0.0' is ambigous.\n\t$ git branch -m v1.0.0-branch\n\n $ git checkout -b v1.0.0\n Switched to a new branch 'v1.0.0'\n\t$ git checkout v1.0.0\n warning: refname 'v1.0.0' is ambigous.\n\tAlready on 'v1.0.0'\n\t$ git branch -m v1.0.0-branch-2\n\nWe should be giving these warning messages immediately after creating\npotentially problematic refs, i.e. just after \"git branch v1.0.0\" and\n\"git checkout -b v1.0.0\". The user experience should look like this\ninstead:\n\n\t$ git branch v1.0.0\n warning: refname 'v1.0.0' is ambiguous.\n advice: you may want to rename it to an unambigous name with\n advice: git branch -m v1.0.0 v1.0.0-branch\n\t$ git branch -m v1.0.0 v1.0.0-branch ;# thanks for an advice\n\n $ git checkout -b v1.0.0\n warning: refname 'v1.0.0' is ambiguous.\n advice: you may want to rename it to an unambigous name with\n advice: git branch -m v1.0.0-branch-2\n\t$ git branch -m v1.0.0-branch-2 ;# thanks for an advice\n"},{"id":"173713","messageId":"87k4abfl2a.fsf@gmail.com","threadId":"28138","inReplyTo":"7vhb5fev8a.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Disallow creating ambiguous branch names by default","fromName":"Vijay Lakshminarayanan","fromEmail":"laksvij@gmail.com","sentAt":"2011-08-18T03:35:57Z","receivedAt":"2011-08-18T03:35:57Z","isPatch":true,"sender":{"key":"laksvij@gmail.com","avatar":null},"body":"Junio C Hamano writes:\n\n> We should be giving these warning messages immediately after creating\n> potentially problematic refs, i.e. just after \"git branch v1.0.0\" and\n> \"git checkout -b v1.0.0\". The user experience should look like this\n> instead:\n>\n> \t$ git branch v1.0.0\n> warning: refname 'v1.0.0' is ambiguous.\n> advice: you may want to rename it to an unambigous name with\n> advice: git branch -m v1.0.0 v1.0.0-branch\n> \t$ git branch -m v1.0.0 v1.0.0-branch ;# thanks for an advice\n>\n> $ git checkout -b v1.0.0\n> warning: refname 'v1.0.0' is ambiguous.\n> advice: you may want to rename it to an unambigous name with\n> advice: git branch -m v1.0.0-branch-2\n> \t$ git branch -m v1.0.0-branch-2 ;# thanks for an advice\n\nI'm not familiar with the git codebase, but I'm guessing this is\nambiguous because there's already a tag by name v1.0.0. /If/ that's the\ncase, wouldn't be be prudent to explain why the branch name is\nambiguous?\n\nJust my 2c.\n\n-- \nCheers\n~vijay\n\nGnus should be more complicated.\n"},{"id":"173758","messageId":"14776204.81375.1313675595871.JavaMail.root@mail.hq.genarts.com","threadId":"28138","inReplyTo":"7vhb5fev8a.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Disallow creating ambiguous branch names by default","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2011-08-18T13:53:15Z","receivedAt":"2011-08-18T13:53:15Z","isPatch":true,"sender":{"key":"bash@genarts.com","avatar":null},"body":"----- Original Message -----\n> From: \"Junio C Hamano\" \n> To: \"Conrad Irwin\" \n> Sent: Wednesday, August 17, 2011 2:41:41 PM\n> Subject: Re: [PATCH] Disallow creating ambiguous branch names by default\n>\n> We should be giving these warning messages immediately after creating\n> potentially problematic refs, i.e. just after \"git branch v1.0.0\" and\n> \"git checkout -b v1.0.0\". The user experience should look like this\n> instead:\n> \n> $ git branch v1.0.0\n> warning: refname 'v1.0.0' is ambiguous.\n> advice: you may want to rename it to an unambigous name with\n> advice: git branch -m v1.0.0 v1.0.0-branch\n> $ git branch -m v1.0.0 v1.0.0-branch ;# thanks for an advice\n> \n> $ git checkout -b v1.0.0\n> warning: refname 'v1.0.0' is ambiguous.\n> advice: you may want to rename it to an unambigous name with\n> advice: git branch -m v1.0.0-branch-2\n> $ git branch -m v1.0.0-branch-2 ;# thanks for an advice\n\nShould case insensitive matches be added to the tests? This morning I discovered coworkers working on branches foo and Foo thinking they were on the same branch... Rather trivial to clean up, but certainly caused some confusion in the office.\n\nThanks,\nStephen\n"},{"id":"173871","messageId":"CAOTq_ptdf3NvoeQXzdABdnU50w1ZwL=wnF6rPJvZpnqcU64-+g@mail.gmail.com","threadId":"28138","inReplyTo":"14776204.81375.1313675595871.JavaMail.root@mail.hq.genarts.com","subject":"Re: [PATCH] Disallow creating ambiguous branch names by default","fromName":"Conrad Irwin","fromEmail":"conrad.irwin@gmail.com","sentAt":"2011-08-19T18:07:53Z","receivedAt":"2011-08-19T18:07:53Z","isPatch":true,"sender":{"key":"conrad.irwin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94272?v=4"},"body":"On Thu, Aug 18, 2011 at 6:53 AM, Stephen Bash wrote:\n>\n> Should case insensitive matches be added to the tests?  This morning I discovered coworkers working on branches foo and Foo thinking they were on the same branch...  Rather trivial to clean up, but certainly caused some confusion in the office.\n>\n\nI can certainly see the use-case, but there's definitely a step-change\nbetween \"this branch has the same name as something else\", and \"this\nbranch is going to confuse you\". When trying to change the code to be\na warning as Junio suggested, I did think about expanding the\ndefinition of ambiguous to include things that are merely confusing;\nhowever it's not clear where to stop (i.e. should we warn about\n/, foo and f00, a branch called \" \" [the\nnon-breaking space]). There's probably an argument for more general\nwarning, but I don't think I understand when it should be shown\nwell-enough.\n\nConrad\n"},{"id":"173872","messageId":"CAOTq_ptU2QmPMMZYQLd2MFQ_=_RnADdBnoN5+v4rXh_nmpOcjw@mail.gmail.com","threadId":"28138","inReplyTo":"7vhb5fev8a.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Disallow creating ambiguous branch names by default","fromName":"Conrad Irwin","fromEmail":"conrad.irwin@gmail.com","sentAt":"2011-08-19T18:14:11Z","receivedAt":"2011-08-19T18:14:11Z","isPatch":true,"sender":{"key":"conrad.irwin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94272?v=4"},"body":"On Wed, Aug 17, 2011 at 11:41 AM, Junio C Hamano wrote:\n> Conrad Irwin writes:\n>\n>> Before this change, it was comparatively easy to create a confusingly\n>\n> Drop everything before the \", \".\n>\n>> named branch (like \"origin/master\" or \"tag.1\"). The former case is\n>> particularly biting to newcomers, who suddenly find themselves needing\n>> to handle nuances of the refs namespaces.\n>\n> If you start forbidding certain names, newcomers will need to be exposed\n> the same nuances to understand why what they wanted to do is not allowed,\n> so that is not an argument.\n>\n> My preferences (take them as \"the ground rules\" if you want) are:\n>\n>  - We don't disallow what we have long allowed, without a good reason;\n>  - We make sure new people will get a warning with useful advice.\n>\n> I would be happy to see the end result that warns when the end user\n> creates a branch (or a tag) that is ambiguous _when_ it is created (not\n> \"much later, when we noticed there are ambiguous refs\"), and offers an\n> advice message to use \"branch -m\" to rename it away (control the message\n> with a new \"advice.*\" configuration and unless explicitly declined with\n> it, always give the advice).\n>\n\nIn the process of changing things around to do this, I noticed that\n\ngit checkout -M \n\nsurprisingly works, and does confusing things, in that you will get a:\n\n$ git rev-parse HEAD@{1}\nwarning: Log .git/logs/HEAD has gap after Fri, 19 Aug 2011 02:00:09 -0700\n\nPresumably this is the reason that git branch -f forbids you from\nchanging the current branch?\n\nIf so is this a reasonable case where the current behaviour should be\nforbidden (with the same error message \"fatal: Cannot force update the\ncurrent branch.\") — or should I just make it output a warning?\n\nConrad\n"},{"id":"173873","messageId":"26995656.83614.1313777742247.JavaMail.root@mail.hq.genarts.com","threadId":"28138","inReplyTo":"CAOTq_ptdf3NvoeQXzdABdnU50w1ZwL=wnF6rPJvZpnqcU64-+g@mail.gmail.com","subject":"Re: [PATCH] Disallow creating ambiguous branch names by default","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2011-08-19T18:15:42Z","receivedAt":"2011-08-19T18:15:42Z","isPatch":true,"sender":{"key":"bash@genarts.com","avatar":null},"body":"----- Original Message -----\n> From: \"Conrad Irwin\" \n> To: \"Stephen Bash\" \n> Cc: \"Junio C Hamano\" , git@vger.kernel.org\n> Sent: Friday, August 19, 2011 2:07:53 PM\n> Subject: Re: [PATCH] Disallow creating ambiguous branch names by default\n>\n> > Should case insensitive matches be added to the tests? This morning\n> > I discovered coworkers working on branches foo and Foo thinking they\n> > were on the same branch... Rather trivial to clean up, but certainly\n> > caused some confusion in the office.\n> \n> I can certainly see the use-case, but there's definitely a step-change\n> between \"this branch has the same name as something else\", and \"this\n> branch is going to confuse you\".\n\nGood point. I'd be curious if any of the msys/cygwin guys can comment on if/when capitalization in branch names becomes technically ambiguous? I would think unpacked refs on a Windows machine could get complicated... And I guess factory Macs are all formated case-insensitive as well, so the same problem might apply there.\n\n> When trying to change the code to be\n> a warning as Junio suggested, I did think about expanding the\n> definition of ambiguous to include things that are merely confusing;\n> however it's not clear where to stop (i.e. should we warn about\n> /, foo and f00, a branch called \" \" [the\n> non-breaking space]). There's probably an argument for more general\n> warning, but I don't think I understand when it should be shown\n> well-enough.\n\nThanks for putting the thought into it, I agree it is a slippery slope.\n\nStephen\n"},{"id":"173881","messageId":"7v1uwh2kks.fsf@alter.siamese.dyndns.org","threadId":"28138","inReplyTo":"CAOTq_ptU2QmPMMZYQLd2MFQ_=_RnADdBnoN5+v4rXh_nmpOcjw@mail.gmail.com","subject":"Re: [PATCH] Disallow creating ambiguous branch names by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-19T20:49:23Z","receivedAt":"2011-08-19T20:49:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Conrad Irwin writes:\n\n> In the process of changing things around to do this, I noticed that\n>\n> git checkout -M \n>\n> surprisingly works,...\n\nWhat is \"-M\" supposed to do???\n\nIf you meant \"-B\", that should work. When I want to rewrite a topic in a\nnon-trivial way, I would often do:\n\n\t$ git checkout HEAD^^^\n work to redo what the few commits at the tip should have done,\n creating commits.\n $ git diff @{-1} HEAD\n $ git checkout -B @{-1}\n\nwhich often happens to be simpler and more flexible than the canned\nrewriting options \"rebase -i\" can offer me.\n\n> ... in that you will get a:\n>\n> $ git rev-parse HEAD@{1}\n> warning: Log .git/logs/HEAD has gap after Fri, 19 Aug 2011 02:00:09 -0700\n\nIf that is the case, then the codepath to update the reflog is\nbroken. That is not a reason to forbid -B, though.\n\nBut because I do not know what you meant by \"checkout -M\", ...\n"},{"id":"173883","messageId":"CAOTq_pskn-yA8tLbJ_tkAC7Dgn2vJ5OK5d5BqOWSna_FVARs_A@mail.gmail.com","threadId":"28138","inReplyTo":"7v1uwh2kks.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Disallow creating ambiguous branch names by default","fromName":"Conrad Irwin","fromEmail":"conrad.irwin@gmail.com","sentAt":"2011-08-19T21:07:57Z","receivedAt":"2011-08-19T21:07:57Z","isPatch":true,"sender":{"key":"conrad.irwin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94272?v=4"},"body":"On Fri, Aug 19, 2011 at 1:49 PM, Junio C Hamano wrote:\n>> $ git rev-parse HEAD@{1}\n>> warning: Log .git/logs/HEAD has gap after Fri, 19 Aug 2011 02:00:09 -0700\n>\n> If that is the case, then the codepath to update the reflog is\n> broken. That is not a reason to forbid -B, though.\n>\n> But because I do not know what you meant by \"checkout -M\", ...\n\nSorry, I meant git branch -M \n\nConrad\n"},{"id":"173887","messageId":"7vwre9133k.fsf@alter.siamese.dyndns.org","threadId":"28138","inReplyTo":"CAOTq_ptU2QmPMMZYQLd2MFQ_=_RnADdBnoN5+v4rXh_nmpOcjw@mail.gmail.com","subject":"Re: [PATCH] Disallow creating ambiguous branch names by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-19T21:52:15Z","receivedAt":"2011-08-19T21:52:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Conrad Irwin writes:\n\n> In the process of changing things around to do this, I noticed that\n>\n> git branch -M \n>\n> surprisingly works, and does confusing things, in that you will get a:\n>\n> $ git rev-parse HEAD@{1}\n> warning: Log .git/logs/HEAD has gap after Fri, 19 Aug 2011 02:00:09 -0700\n>\n> Presumably this is the reason that git branch -f forbids you from\n> changing the current branch?\n\n[jc: edited typo in the original command exhibition]\n\nI also suspect that \"git status\" will become nonsense at that point, as\nthe working tree and the index were still the original state while the\ncommit pointed by HEAD have changed underneath you.\n\nAnd you are correct to point out that it is why \"git branch -f\" shouldn't\ntouch the current branch. We should notice the situation and error out.\n\nPatches welcome.\n\nI initially thought that such a patch can optionally as a bonus suggest an\nalternative way to confuse yourself, e.g. \"git reset --soft \", which\nis what is happening, but I do not think it makes sense, especially with\n\"--soft\", either.\n\nThe user is saying \"I know the exists already, and I want\nit to match the tip of branch\", without saying what should happen to\nwhat is in the working tree, so depending on what s/he wants, either \"git\nreset --hard \" or \"git reset --keep \" followed by \"git branch -d\nfoo\" would be the right thing to do, and I would imagine that one could\neven argue that \"git branch -M \" should do exactly\nthat under the hood, but the may be a typo and the user\nmay have meant to affect some other branch, so in order to play it safe,\njust an error message without any advice based on a vague second-guess of\nthe user's intention, would be the most appropriate, I would think.\n\nThanks.\n"}]}