{"thread":{"id":"34124","subject":"[PATCH 2/6] rebase: prepare to write reflog message for checkout","startedAt":"2013-06-13T13:32:23Z","lastAt":"2013-06-16T06:07:43Z","messageCount":37,"participants":["Ramkumar Ramachandra","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":6},"messages":[{"id":"220724","messageId":"1371130349-30651-1-git-send-email-artagnon@gmail.com","threadId":"34124","inReplyTo":null,"subject":"[PATCH 0/6] Fix git checkout - with rebase","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T13:32:23Z","receivedAt":"2013-06-13T13:32:23Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nI'm happy to report that I have found a reasonable solution\nto the problem: see [5/6].\n\nThe larger problem still persists: in my opinion, b397ea4 takes the\nwrong approach to the problem it is attempting to solve; nobody cares\n_how_ I got to a detached HEAD state; what is important is that I'm\nstuck in such a state and need useful information.\n\nThe correct approach, in my opinion, is already taken by my prompt:\nuse git describe.\n\n  artagnon|checkout-dash=$ git checkout @~1\n  artagnon|(checkout-dash~1):~/src/git$\n\nNow compare this with the approach taken by the patch:\n\n  artagnon|(checkout-dash~1):~/src/git$ git status\n  # HEAD detached at 7aa7992\n  nothing added to commit but untracked files present\n\nCompletely useless.\n\nUnfortunately, it is too late to revert b397ea4, as too much stuff\nalready depends on it now (see builtin/branch.c for example).\nReworking the code to use describe is not an easy task at all:\ndescribe has no exposed API, and is polluted with die() statements.\nNevertheless, it can be a fruitful exercise for someone who is willing\nto take on the challenge.\n\nThanks.\n\nRamkumar Ramachandra (6):\n  t/checkout-last: checkout - doesn't work after rebase\n  rebase: prepare to write reflog message for checkout\n  rebase -i: prepare to write reflog message for checkout\n  wt-status: remove unused field in grab_1st_switch_cbdata\n  status: do not depend on flaky reflog messages\n  checkout: respect GIT_REFLOG_ACTION\n\n builtin/checkout.c         | 11 ++++++++---\n git-rebase--interactive.sh |  2 ++\n git-rebase.sh              |  2 ++\n t/t2012-checkout-last.sh   | 16 ++++++++++++++++\n t/t7512-status-help.sh     | 37 +++++++++++++++++--------------------\n wt-status.c                | 13 ++++---------\n 6 files changed, 49 insertions(+), 32 deletions(-)\n\n-- \n1.8.3.1.384.g7cec0b4\n"},{"id":"220727","messageId":"1371130349-30651-2-git-send-email-artagnon@gmail.com","threadId":"34124","inReplyTo":"1371130349-30651-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 1/6] t/checkout-last: checkout - doesn't work after rebase","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T13:32:24Z","receivedAt":"2013-06-13T13:32:24Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"The following command\n\n  $ git checkout -\n\ndoes not work as expected after a rebase.  Every kind of rebase must\nbehave in the exactly same way: for the purposes of checkout -, the\nrebase event should be inconsequential.\n\nAdd two failing tests documenting this bug: one for a normal rebase, and\nanother for an interactive rebase.\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n t/t2012-checkout-last.sh | 16 ++++++++++++++++\n 1 file changed, 16 insertions(+)\n\ndiff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh\nindex b44de9d..ae6d319 100755\n--- a/t/t2012-checkout-last.sh\n+++ b/t/t2012-checkout-last.sh\n@@ -116,4 +116,20 @@ test_expect_success 'master...' '\n \ttest \"z$(git rev-parse --verify HEAD)\" = \"z$(git rev-parse --verify master^)\"\n '\n \n+test_expect_failure '\"checkout -\" works after a rebase' '\n+\tgit checkout master &&\n+\tgit checkout other &&\n+\tgit rebase master &&\n+\tgit checkout - &&\n+\ttest \"z$(git symbolic-ref HEAD)\" = \"zrefs/heads/master\"\n+'\n+\n+test_expect_failure '\"checkout -\" works after an interactive rebase' '\n+\tgit checkout master &&\n+\tgit checkout other &&\n+\tgit rebase -i master &&\n+\tgit checkout - &&\n+\ttest \"z$(git symbolic-ref HEAD)\" = \"zrefs/heads/master\"\n+'\n+\n test_done\n-- \n1.8.3.1.384.g7cec0b4\n"},{"id":"220721","messageId":"1371130349-30651-3-git-send-email-artagnon@gmail.com","threadId":"34124","inReplyTo":"1371130349-30651-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 2/6] rebase: prepare to write reflog message for checkout","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T13:32:25Z","receivedAt":"2013-06-13T13:32:25Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"rebase should never write \"checkout: \" messages to the reflog, since it\nis highly confusing to the end user, and breaks\ngrab_nth_branch_checkout(), as demonstrated by failing tests\nin t/checkout-last.  Set a sensible GIT_REFLOG_ACTION: checkout does not\nrespect GIT_REFLOG_ACTION yet, but this defect will be addressed in a\nfuture patch.\n\nWhen the defect is addressed, rebase will write the following line to\nthe reflog when started:\n\n  rebase: checkout master\n\nThis is much better than the confusing message it currently writes:\n\n  checkout: moving from master to 1462b67\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n git-rebase.sh | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex d0c11a9..6587019 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -568,6 +568,8 @@ test \"$type\" = interactive && run_specific_rebase\n \n # Detach HEAD and reset the tree\n say \"$(gettext \"First, rewinding head to replay your work on top of it...\")\"\n+\n+GIT_REFLOG_ACTION=\"$GIT_REFLOG_ACTION: checkout $onto_name\"\n git checkout -q \"$onto^0\" || die \"could not detach HEAD\"\n git update-ref ORIG_HEAD $orig_head\n \n-- \n1.8.3.1.384.g7cec0b4\n"},{"id":"220726","messageId":"1371130349-30651-4-git-send-email-artagnon@gmail.com","threadId":"34124","inReplyTo":"1371130349-30651-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 3/6] rebase -i: prepare to write reflog message for checkout","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T13:32:26Z","receivedAt":"2013-06-13T13:32:26Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Interactive rebase should never write \"checkout: \" messages to the\nreflog, since it is highly confusing to the end user, and breaks\ngrab_nth_branch_checkout(), as demonstrated by failing tests\nin t/checkout-last.  Set a sensible GIT_REFLOG_ACTION: checkout does not\nrespect GIT_REFLOG_ACTION yet, but this defect will be addressed in a\nfuture patch.\n\nWhen the defect is addressed, rebase -i will write the following line to\nthe reflog when started:\n\n  rebase -i (start): checkout master\n\nThis is much better than the confusing message it currently writes:\n\n  checkout: moving from master to 1462b67\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n git-rebase--interactive.sh | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex f953d8d..0f04425 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -838,6 +838,7 @@ comment_for_reflog start\n \n if test ! -z \"$switch_to\"\n then\n+\tGIT_REFLOG_ACTION=\"$GIT_REFLOG_ACTION: checkout $switch_to\"\n \toutput git checkout \"$switch_to\" -- ||\n \t\tdie \"Could not checkout $switch_to\"\n fi\n@@ -981,6 +982,7 @@ has_action \"$todo\" ||\n \n test -d \"$rewritten\" || test -n \"$force_rebase\" || skip_unnecessary_picks\n \n+GIT_REFLOG_ACTION=\"$GIT_REFLOG_ACTION: checkout $onto_name\"\n output git checkout $onto || die_abort \"could not detach HEAD\"\n git update-ref ORIG_HEAD $orig_head\n do_rest\n-- \n1.8.3.1.384.g7cec0b4\n"},{"id":"220722","messageId":"1371130349-30651-5-git-send-email-artagnon@gmail.com","threadId":"34124","inReplyTo":"1371130349-30651-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 4/6] wt-status: remove unused field in grab_1st_switch_cbdata","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T13:32:27Z","receivedAt":"2013-06-13T13:32:27Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"The struct grab_1st_switch_cbdata has the field \"found\", which is set in\ngrab_1st_switch() when a match is found.  This information is redundant\nand unused by any caller: the return value of the function serves to\ncommunicate this information anyway.  Remove the field.\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n wt-status.c | 2 --\n 1 file changed, 2 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex bf84a86..2511270 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -1035,7 +1035,6 @@ got_nothing:\n }\n \n struct grab_1st_switch_cbdata {\n-\tint found;\n \tstruct strbuf buf;\n \tunsigned char nsha1[20];\n };\n@@ -1059,7 +1058,6 @@ static int grab_1st_switch(unsigned char *osha1, unsigned char *nsha1,\n \tfor (end = target; *end && *end != '\\n'; end++)\n \t\t;\n \tstrbuf_add(&cb->buf, target, end - target);\n-\tcb->found = 1;\n \treturn 1;\n }\n \n-- \n1.8.3.1.384.g7cec0b4\n"},{"id":"220723","messageId":"1371130349-30651-6-git-send-email-artagnon@gmail.com","threadId":"34124","inReplyTo":"1371130349-30651-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T13:32:28Z","receivedAt":"2013-06-13T13:32:28Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"b397ea4 (status: show more info than \"currently not on any branch\",\n2013-03-13) made the output of 'git status' richer in the case of a\ndetached HEAD.  Before this patch, with a detached HEAD:\n\n  $ git status\n  # Not currently on any branch.\n\nAfter the patch:\n\n  $ git checkout v1.8.2\n  # HEAD is now detached\n  $ git status\n  # HEAD detached at v1.8.2.\n\nIt works by digging the reflog for the most recent message of the form\n\"checkout: moving from xxxx to yyyy\".  It then asserts that HEAD and\n\"yyyy\" are the same, and displays this message.  When they aren't equal,\nit displays:\n\n  $ git status\n  # HEAD detached from fe11db.\n\nAt this point, the utility of such a message is in question.  Moreover,\nthere are several tests in t/status-help that explicitly rely on rebase\nwriting \"checkout: \" messages to the reflog.  As evidenced by the\nfailing tests in t/checkout-last, these messages are completely\nunintended and flaky.  Relying on them only makes it harder to improve\nthe reflog messages written by scripts.  As a reasonable compromise,\nremove the logic to display the \"HEAD detached from ...\" message, and\nfallback to \"Not currently on any branch.\" in this case.  Update the\ntests, giving scripts some breathing space.\n\nThis issue is not isolated to rebase at all.  Several other scripts like\nbisect write (confusing) \"checkout: \" messages to the reflog.  Fixing\nthem is left as an exercise to other contributors.\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n t/t7512-status-help.sh | 24 +++++++++++-------------\n wt-status.c            | 11 ++++-------\n 2 files changed, 15 insertions(+), 20 deletions(-)\n\ndiff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh\nindex bf08d4e..ed9d57c 100755\n--- a/t/t7512-status-help.sh\n+++ b/t/t7512-status-help.sh\n@@ -188,10 +188,9 @@ test_expect_success 'status when rebasing -i in edit mode' '\n \texport FAKE_LINES &&\n \ttest_when_finished \"git rebase --abort\" &&\n \tONTO=$(git rev-parse --short HEAD~2) &&\n-\tTGT=$(git rev-parse --short two_rebase_i) &&\n \tgit rebase -i HEAD~2 &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $TGT\n+\t# Not currently on any branch.\n \t# You are currently editing a commit while rebasing branch '\\''rebase_i_edit'\\'' on '\\''$ONTO'\\''.\n \t#   (use \"git commit --amend\" to amend the current commit)\n \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n@@ -246,11 +245,10 @@ test_expect_success 'status after editing the last commit with --amend during a\n \texport FAKE_LINES &&\n \ttest_when_finished \"git rebase --abort\" &&\n \tONTO=$(git rev-parse --short HEAD~3) &&\n-\tTGT=$(git rev-parse --short three_amend) &&\n \tgit rebase -i HEAD~3 &&\n \tgit commit --amend -m \"foo\" &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $TGT\n+\t# Not currently on any branch.\n \t# You are currently editing a commit while rebasing branch '\\''amend_last'\\'' on '\\''$ONTO'\\''.\n \t#   (use \"git commit --amend\" to amend the current commit)\n \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n@@ -280,7 +278,7 @@ test_expect_success 'status: (continue first edit) second edit' '\n \tgit rebase -i HEAD~3 &&\n \tgit rebase --continue &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $ONTO\n+\t# Not currently on any branch.\n \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n \t#   (use \"git commit --amend\" to amend the current commit)\n \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n@@ -302,7 +300,7 @@ test_expect_success 'status: (continue first edit) second edit and split' '\n \tgit rebase --continue &&\n \tgit reset HEAD^ &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $ONTO\n+\t# Not currently on any branch.\n \t# You are currently splitting a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n \t#   (Once your working directory is clean, run \"git rebase --continue\")\n \t#\n@@ -329,7 +327,7 @@ test_expect_success 'status: (continue first edit) second edit and amend' '\n \tgit rebase --continue &&\n \tgit commit --amend -m \"foo\" &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $ONTO\n+\t# Not currently on any branch.\n \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n \t#   (use \"git commit --amend\" to amend the current commit)\n \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n@@ -351,7 +349,7 @@ test_expect_success 'status: (amend first edit) second edit' '\n \tgit commit --amend -m \"a\" &&\n \tgit rebase --continue &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $ONTO\n+\t# Not currently on any branch.\n \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n \t#   (use \"git commit --amend\" to amend the current commit)\n \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n@@ -374,7 +372,7 @@ test_expect_success 'status: (amend first edit) second edit and split' '\n \tgit rebase --continue &&\n \tgit reset HEAD^ &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $ONTO\n+\t# Not currently on any branch.\n \t# You are currently splitting a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n \t#   (Once your working directory is clean, run \"git rebase --continue\")\n \t#\n@@ -402,7 +400,7 @@ test_expect_success 'status: (amend first edit) second edit and amend' '\n \tgit rebase --continue &&\n \tgit commit --amend -m \"d\" &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $ONTO\n+\t# Not currently on any branch.\n \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n \t#   (use \"git commit --amend\" to amend the current commit)\n \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n@@ -426,7 +424,7 @@ test_expect_success 'status: (split first edit) second edit' '\n \tgit commit -m \"e\" &&\n \tgit rebase --continue &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $ONTO\n+\t# Not currently on any branch.\n \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n \t#   (use \"git commit --amend\" to amend the current commit)\n \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n@@ -451,7 +449,7 @@ test_expect_success 'status: (split first edit) second edit and split' '\n \tgit rebase --continue &&\n \tgit reset HEAD^ &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $ONTO\n+\t# Not currently on any branch.\n \t# You are currently splitting a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n \t#   (Once your working directory is clean, run \"git rebase --continue\")\n \t#\n@@ -481,7 +479,7 @@ test_expect_success 'status: (split first edit) second edit and amend' '\n \tgit rebase --continue &&\n \tgit commit --amend -m \"h\" &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached from $ONTO\n+\t# Not currently on any branch.\n \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n \t#   (use \"git commit --amend\" to amend the current commit)\n \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\ndiff --git a/wt-status.c b/wt-status.c\nindex 2511270..f7d46a1 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -1173,15 +1173,12 @@ void wt_status_print(struct wt_status *s)\n \t\tif (!prefixcmp(branch_name, \"refs/heads/\"))\n \t\t\tbranch_name += 11;\n \t\telse if (!strcmp(branch_name, \"HEAD\")) {\n+\t\t\tunsigned char sha1[20];\n \t\t\tbranch_status_color = color(WT_STATUS_NOBRANCH, s);\n-\t\t\tif (state.detached_from) {\n-\t\t\t\tunsigned char sha1[20];\n+\t\t\tif (state.detached_from && !get_sha1(\"HEAD\", sha1) &&\n+\t\t\t\t!hashcmp(sha1, state.detached_sha1)) {\n \t\t\t\tbranch_name = state.detached_from;\n-\t\t\t\tif (!get_sha1(\"HEAD\", sha1) &&\n-\t\t\t\t    !hashcmp(sha1, state.detached_sha1))\n-\t\t\t\t\ton_what = _(\"HEAD detached at \");\n-\t\t\t\telse\n-\t\t\t\t\ton_what = _(\"HEAD detached from \");\n+\t\t\t\ton_what = _(\"HEAD detached at \");\n \t\t\t} else {\n \t\t\t\tbranch_name = \"\";\n \t\t\t\ton_what = _(\"Not currently on any branch.\");\n-- \n1.8.3.1.384.g7cec0b4\n"},{"id":"220725","messageId":"1371130349-30651-7-git-send-email-artagnon@gmail.com","threadId":"34124","inReplyTo":"1371130349-30651-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 6/6] checkout: respect GIT_REFLOG_ACTION","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T13:32:29Z","receivedAt":"2013-06-13T13:32:29Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"GIT_REFLOG_ACTION is an environment variable specifying the reflog\nmessage to write after an action is completed.  Several other commands\nincluding merge, reset, and commit respect it.\n\nFix the failing tests in t/checkout-last by making checkout respect it\ntoo.  You can now expect\n\n  $ git checkout -\n\nto work as expected after any rebase operation.\n\nAlso update the tests in t/status-help that rely on rebase writing\n\"checkout: \" messages to the reflog.\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n builtin/checkout.c       | 11 ++++++++---\n t/t2012-checkout-last.sh |  4 ++--\n t/t7512-status-help.sh   | 13 ++++++-------\n 3 files changed, 16 insertions(+), 12 deletions(-)\n\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex f5b50e5..1e2af85 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -587,7 +587,7 @@ static void update_refs_for_switch(const struct checkout_opts *opts,\n \t\t\t\t   struct branch_info *new)\n {\n \tstruct strbuf msg = STRBUF_INIT;\n-\tconst char *old_desc;\n+\tconst char *old_desc, *reflog_msg;\n \tif (opts->new_branch) {\n \t\tif (opts->new_orphan_branch) {\n \t\t\tif (opts->new_branch_log && !log_all_ref_updates) {\n@@ -620,8 +620,13 @@ static void update_refs_for_switch(const struct checkout_opts *opts,\n \told_desc = old->name;\n \tif (!old_desc && old->commit)\n \t\told_desc = sha1_to_hex(old->commit->object.sha1);\n-\tstrbuf_addf(&msg, \"checkout: moving from %s to %s\",\n-\t\t    old_desc ? old_desc : \"(invalid)\", new->name);\n+\n+\treflog_msg = getenv(\"GIT_REFLOG_ACTION\");\n+\tif (!reflog_msg)\n+\t\tstrbuf_addf(&msg, \"checkout: moving from %s to %s\",\n+\t\t\told_desc ? old_desc : \"(invalid)\", new->name);\n+\telse\n+\t\tstrbuf_insert(&msg, 0, reflog_msg, strlen(reflog_msg));\n \n \tif (!strcmp(new->name, \"HEAD\") && !new->path && !opts->force_detach) {\n \t\t/* Nothing to do. */\ndiff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh\nindex ae6d319..336b6f2 100755\n--- a/t/t2012-checkout-last.sh\n+++ b/t/t2012-checkout-last.sh\n@@ -116,7 +116,7 @@ test_expect_success 'master...' '\n \ttest \"z$(git rev-parse --verify HEAD)\" = \"z$(git rev-parse --verify master^)\"\n '\n \n-test_expect_failure '\"checkout -\" works after a rebase' '\n+test_expect_success '\"checkout -\" works after a rebase' '\n \tgit checkout master &&\n \tgit checkout other &&\n \tgit rebase master &&\n@@ -124,7 +124,7 @@ test_expect_failure '\"checkout -\" works after a rebase' '\n \ttest \"z$(git symbolic-ref HEAD)\" = \"zrefs/heads/master\"\n '\n \n-test_expect_failure '\"checkout -\" works after an interactive rebase' '\n+test_expect_success '\"checkout -\" works after an interactive rebase' '\n \tgit checkout master &&\n \tgit checkout other &&\n \tgit rebase -i master &&\ndiff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh\nindex ed9d57c..f8661e4 100755\n--- a/t/t7512-status-help.sh\n+++ b/t/t7512-status-help.sh\n@@ -77,7 +77,7 @@ test_expect_success 'status when rebase in progress before resolving conflicts'\n \tONTO=$(git rev-parse --short HEAD^^) &&\n \ttest_must_fail git rebase HEAD^ --onto HEAD^^ &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached at $ONTO\n+\t# Not currently on any branch.\n \t# You are currently rebasing branch '\\''rebase_conflicts'\\'' on '\\''$ONTO'\\''.\n \t#   (fix conflicts and then run \"git rebase --continue\")\n \t#   (use \"git rebase --skip\" to skip this patch)\n@@ -104,7 +104,7 @@ test_expect_success 'status when rebase in progress before rebase --continue' '\n \techo three >main.txt &&\n \tgit add main.txt &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached at $ONTO\n+\t# Not currently on any branch.\n \t# You are currently rebasing branch '\\''rebase_conflicts'\\'' on '\\''$ONTO'\\''.\n \t#   (all conflicts fixed: run \"git rebase --continue\")\n \t#\n@@ -136,7 +136,7 @@ test_expect_success 'status during rebase -i when conflicts unresolved' '\n \tONTO=$(git rev-parse --short rebase_i_conflicts) &&\n \ttest_must_fail git rebase -i rebase_i_conflicts &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached at $ONTO\n+\t# Not currently on any branch.\n \t# You are currently rebasing branch '\\''rebase_i_conflicts_second'\\'' on '\\''$ONTO'\\''.\n \t#   (fix conflicts and then run \"git rebase --continue\")\n \t#   (use \"git rebase --skip\" to skip this patch)\n@@ -162,7 +162,7 @@ test_expect_success 'status during rebase -i after resolving conflicts' '\n \ttest_must_fail git rebase -i rebase_i_conflicts &&\n \tgit add main.txt &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached at $ONTO\n+\t# Not currently on any branch.\n \t# You are currently rebasing branch '\\''rebase_i_conflicts_second'\\'' on '\\''$ONTO'\\''.\n \t#   (all conflicts fixed: run \"git rebase --continue\")\n \t#\n@@ -215,9 +215,8 @@ test_expect_success 'status when splitting a commit' '\n \tONTO=$(git rev-parse --short HEAD~3) &&\n \tgit rebase -i HEAD~3 &&\n \tgit reset HEAD^ &&\n-\tTGT=$(git rev-parse --short HEAD) &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached at $TGT\n+\t# Not currently on any branch.\n \t# You are currently splitting a commit while rebasing branch '\\''split_commit'\\'' on '\\''$ONTO'\\''.\n \t#   (Once your working directory is clean, run \"git rebase --continue\")\n \t#\n@@ -599,7 +598,7 @@ test_expect_success 'status when rebase conflicts with statushints disabled' '\n \tONTO=$(git rev-parse --short HEAD^^) &&\n \ttest_must_fail git rebase HEAD^ --onto HEAD^^ &&\n \tcat >expected <<-EOF &&\n-\t# HEAD detached at $ONTO\n+\t# Not currently on any branch.\n \t# You are currently rebasing branch '\\''statushints_disabled'\\'' on '\\''$ONTO'\\''.\n \t#\n \t# Unmerged paths:\n-- \n1.8.3.1.384.g7cec0b4\n"},{"id":"220748","messageId":"7vfvwlvr7e.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"1371130349-30651-2-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 1/6] t/checkout-last: checkout - doesn't work after rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-13T17:46:45Z","receivedAt":"2013-06-13T17:46:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> The following command\n>\n>   $ git checkout -\n>\n> does not work as expected after a rebase.  Every kind of rebase must\n> behave in the exactly same way: for the purposes of checkout -, the\n> rebase event should be inconsequential.\n>\n> Add two failing tests documenting this bug: one for a normal rebase, and\n> another for an interactive rebase.\n\nWhy two?\n\nAfter the discussion, I would have expected to see the two argument\nform:\n\n\tgit rebase [-i] master other\n        \nstarted on the 'other' branch and also started on a branch that is\nnot 'master' or 'other', also be tested to specify the desired\nbehaviour in these cases.\n\n>\n> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n> ---\n>  t/t2012-checkout-last.sh | 16 ++++++++++++++++\n>  1 file changed, 16 insertions(+)\n>\n> diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh\n> index b44de9d..ae6d319 100755\n> --- a/t/t2012-checkout-last.sh\n> +++ b/t/t2012-checkout-last.sh\n> @@ -116,4 +116,20 @@ test_expect_success 'master...' '\n>  \ttest \"z$(git rev-parse --verify HEAD)\" = \"z$(git rev-parse --verify master^)\"\n>  '\n>  \n> +test_expect_failure '\"checkout -\" works after a rebase' '\n> +\tgit checkout master &&\n> +\tgit checkout other &&\n> +\tgit rebase master &&\n> +\tgit checkout - &&\n> +\ttest \"z$(git symbolic-ref HEAD)\" = \"zrefs/heads/master\"\n> +'\n> +\n> +test_expect_failure '\"checkout -\" works after an interactive rebase' '\n> +\tgit checkout master &&\n> +\tgit checkout other &&\n> +\tgit rebase -i master &&\n> +\tgit checkout - &&\n> +\ttest \"z$(git symbolic-ref HEAD)\" = \"zrefs/heads/master\"\n> +'\n> +\n>  test_done\n"},{"id":"220749","messageId":"7vbo79vqzm.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"1371130349-30651-3-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 2/6] rebase: prepare to write reflog message for checkout","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-13T17:51:25Z","receivedAt":"2013-06-13T17:51:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> rebase should never write \"checkout: \" messages to the reflog, since it\n> is highly confusing to the end user, and breaks\n> grab_nth_branch_checkout(), as demonstrated by failing tests\n> in t/checkout-last.  \n\n\"breaks\" because \"the branch flipping rebase internally does is not\n'checkout' as far as the end user is concerned\", which essentially\nis the tautology with the first part \"should never write\".\n\nI would say\n\n    The branch flipping rebase internally does is not 'checkout' as\n    far as the end user is concerned; rebase should never write\n    \"checkout: \" messages to the reflog.  Instead it should say\n    \"rebase: checkout master\".\n\n> Set a sensible GIT_REFLOG_ACTION: checkout does not\n> respect GIT_REFLOG_ACTION yet, but this defect will be addressed in a\n> future patch.\n\nThat is not a defect; it did not have to so far, until this patch.\n\nI suspect doing 6/6 before this patch may make more sense.\n"},{"id":"220750","messageId":"7v4nd1vqxk.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"1371130349-30651-4-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 3/6] rebase -i: prepare to write reflog message for checkout","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-13T17:52:39Z","receivedAt":"2013-06-13T17:52:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The same comment as 2/6 applies to this one.  What these two do\nmakes sense, but I think having 6/6 before them would make the\nseries easier to follow.\n"},{"id":"220751","messageId":"7vzjutucap.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"1371130349-30651-5-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 4/6] wt-status: remove unused field in grab_1st_switch_cbdata","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-13T17:54:06Z","receivedAt":"2013-06-13T17:54:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> The struct grab_1st_switch_cbdata has the field \"found\", which is set in\n> grab_1st_switch() when a match is found.  This information is redundant\n> and unused by any caller: the return value of the function serves to\n> communicate this information anyway.  Remove the field.\n>\n> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n> ---\n\nGood.\n\n>  wt-status.c | 2 --\n>  1 file changed, 2 deletions(-)\n>\n> diff --git a/wt-status.c b/wt-status.c\n> index bf84a86..2511270 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -1035,7 +1035,6 @@ got_nothing:\n>  }\n>  \n>  struct grab_1st_switch_cbdata {\n> -\tint found;\n>  \tstruct strbuf buf;\n>  \tunsigned char nsha1[20];\n>  };\n> @@ -1059,7 +1058,6 @@ static int grab_1st_switch(unsigned char *osha1, unsigned char *nsha1,\n>  \tfor (end = target; *end && *end != '\\n'; end++)\n>  \t\t;\n>  \tstrbuf_add(&cb->buf, target, end - target);\n> -\tcb->found = 1;\n>  \treturn 1;\n>  }\n"},{"id":"220752","messageId":"CALkWK0k3Wr7x_4NAHzY0xEg7sQG6qLe2cr2tJusGZBNHEtPNHg@mail.gmail.com","threadId":"34124","inReplyTo":"7vbo79vqzm.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/6] rebase: prepare to write reflog message for checkout","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T18:05:13Z","receivedAt":"2013-06-13T18:05:13Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> [...]\n\nWill fix those.\n\n> I suspect doing 6/6 before this patch may make more sense.\n\nYeah, I'd done it like that in the original (early preview thing).\nAllow me to explain why I flipped the ordering.\n\nThe problem I am facing is that 6/6 causes very major breakages, and\n5/6 attempts to minimize that fallout and make life for 6/6 easier.\nThe problem with putting this patch (and the rebase -i) after those\ntwo is simple: it calls set_reflog_action, but never explicitly\nindicates that it wants to set the reflog message for checkout.  As a\nresult, the reflog messages are merely accidental and will look like:\n\n  rebase\n  rebase -i (start)\n\nin both the critical patches (5/6 and 6/6).  This was an absolute\ndebugging disaster for me, and I didn't know what wt-status was trying\nto tell me with its cryptic \"detached HEAD to\" and \"detached HEAD\nfrom\" messages.\n\nMakes sense?\n"},{"id":"220753","messageId":"7vvc5hubox.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"1371130349-30651-6-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-13T18:07:10Z","receivedAt":"2013-06-13T18:07:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> b397ea4 (status: show more info than \"currently not on any branch\",\n> 2013-03-13) made the output of 'git status' richer in the case of a\n> detached HEAD.  Before this patch, with a detached HEAD:\n>\n>   $ git status\n>   # Not currently on any branch.\n>\n> After the patch:\n>\n>   $ git checkout v1.8.2\n>   # HEAD is now detached\n>   $ git status\n>   # HEAD detached at v1.8.2.\n>\n> It works by digging the reflog for the most recent message of the form\n> \"checkout: moving from xxxx to yyyy\".  It then asserts that HEAD and\n> \"yyyy\" are the same, and displays this message.  When they aren't equal,\n> it displays:\n>\n>   $ git status\n>   # HEAD detached from fe11db.\n>\n> At this point, the utility of such a message is in question.\n\nYou can question, but I am not convinced the answer is an\nunambiguous \"not useful\"\n\nYou were at 1.8.2 but no longer are, so in the following sequence:\n\n    $ git checkout v1.8.2\n    $ git status\n    $ git reset --hard HEAD^\n    $ git status\n    \nthe former would say \"detached at v1.8.2\" while the latter should\n*not*, because we are no longer at v1.8.2.  \"detached from v1.8.2\"\nis too subtle a way to express the state, and is confusing, but I\nwould not be surprised if people find it useful to be able to learn\n\"v1.8.2\" even after you strayed away.\n\n> Moreover,\n> there are several tests in t/status-help that explicitly rely on rebase\n> writing \"checkout: \" messages to the reflog.  As evidenced by the\n> failing tests in t/checkout-last, these messages are completely\n> unintended and flaky.  \n\nThe above only helps to convince me that \"rebase should not affect\nwhat the last checked-out branch was by letting 'checkout' it\ninternally calls to write reflog entries for it\"  With patches 6, 2,\nand 3, I thought you fixed that issue.\n\nSo I am not convinced that is a good argument to justify to regress\n\"HEAD detached from\" message to \"Not on any branch\".\n\nAt least, not just yet.\n\n> This issue is not isolated to rebase at all.  Several other scripts like\n> bisect write (confusing) \"checkout: \" messages to the reflog.  Fixing\n> them is left as an exercise to other contributors.\n\nAny scripted Porcelain that use \"checkout\", with patch 6, should be\nable to do so with reflog-action environment variable, right?  And 2\nand 3 are examples of such fixes to two of them, which argues even\nmore strongly that 6 should be earier in the series, I think.\n\n>\n> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n> ---\n>  t/t7512-status-help.sh | 24 +++++++++++-------------\n>  wt-status.c            | 11 ++++-------\n>  2 files changed, 15 insertions(+), 20 deletions(-)\n>\n> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh\n> index bf08d4e..ed9d57c 100755\n> --- a/t/t7512-status-help.sh\n> +++ b/t/t7512-status-help.sh\n> @@ -188,10 +188,9 @@ test_expect_success 'status when rebasing -i in edit mode' '\n>  \texport FAKE_LINES &&\n>  \ttest_when_finished \"git rebase --abort\" &&\n>  \tONTO=$(git rev-parse --short HEAD~2) &&\n> -\tTGT=$(git rev-parse --short two_rebase_i) &&\n>  \tgit rebase -i HEAD~2 &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $TGT\n> +\t# Not currently on any branch.\n>  \t# You are currently editing a commit while rebasing branch '\\''rebase_i_edit'\\'' on '\\''$ONTO'\\''.\n>  \t#   (use \"git commit --amend\" to amend the current commit)\n>  \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n> @@ -246,11 +245,10 @@ test_expect_success 'status after editing the last commit with --amend during a\n>  \texport FAKE_LINES &&\n>  \ttest_when_finished \"git rebase --abort\" &&\n>  \tONTO=$(git rev-parse --short HEAD~3) &&\n> -\tTGT=$(git rev-parse --short three_amend) &&\n>  \tgit rebase -i HEAD~3 &&\n>  \tgit commit --amend -m \"foo\" &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $TGT\n> +\t# Not currently on any branch.\n>  \t# You are currently editing a commit while rebasing branch '\\''amend_last'\\'' on '\\''$ONTO'\\''.\n>  \t#   (use \"git commit --amend\" to amend the current commit)\n>  \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n> @@ -280,7 +278,7 @@ test_expect_success 'status: (continue first edit) second edit' '\n>  \tgit rebase -i HEAD~3 &&\n>  \tgit rebase --continue &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $ONTO\n> +\t# Not currently on any branch.\n>  \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n>  \t#   (use \"git commit --amend\" to amend the current commit)\n>  \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n> @@ -302,7 +300,7 @@ test_expect_success 'status: (continue first edit) second edit and split' '\n>  \tgit rebase --continue &&\n>  \tgit reset HEAD^ &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $ONTO\n> +\t# Not currently on any branch.\n>  \t# You are currently splitting a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n>  \t#   (Once your working directory is clean, run \"git rebase --continue\")\n>  \t#\n> @@ -329,7 +327,7 @@ test_expect_success 'status: (continue first edit) second edit and amend' '\n>  \tgit rebase --continue &&\n>  \tgit commit --amend -m \"foo\" &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $ONTO\n> +\t# Not currently on any branch.\n>  \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n>  \t#   (use \"git commit --amend\" to amend the current commit)\n>  \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n> @@ -351,7 +349,7 @@ test_expect_success 'status: (amend first edit) second edit' '\n>  \tgit commit --amend -m \"a\" &&\n>  \tgit rebase --continue &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $ONTO\n> +\t# Not currently on any branch.\n>  \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n>  \t#   (use \"git commit --amend\" to amend the current commit)\n>  \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n> @@ -374,7 +372,7 @@ test_expect_success 'status: (amend first edit) second edit and split' '\n>  \tgit rebase --continue &&\n>  \tgit reset HEAD^ &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $ONTO\n> +\t# Not currently on any branch.\n>  \t# You are currently splitting a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n>  \t#   (Once your working directory is clean, run \"git rebase --continue\")\n>  \t#\n> @@ -402,7 +400,7 @@ test_expect_success 'status: (amend first edit) second edit and amend' '\n>  \tgit rebase --continue &&\n>  \tgit commit --amend -m \"d\" &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $ONTO\n> +\t# Not currently on any branch.\n>  \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n>  \t#   (use \"git commit --amend\" to amend the current commit)\n>  \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n> @@ -426,7 +424,7 @@ test_expect_success 'status: (split first edit) second edit' '\n>  \tgit commit -m \"e\" &&\n>  \tgit rebase --continue &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $ONTO\n> +\t# Not currently on any branch.\n>  \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n>  \t#   (use \"git commit --amend\" to amend the current commit)\n>  \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n> @@ -451,7 +449,7 @@ test_expect_success 'status: (split first edit) second edit and split' '\n>  \tgit rebase --continue &&\n>  \tgit reset HEAD^ &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $ONTO\n> +\t# Not currently on any branch.\n>  \t# You are currently splitting a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n>  \t#   (Once your working directory is clean, run \"git rebase --continue\")\n>  \t#\n> @@ -481,7 +479,7 @@ test_expect_success 'status: (split first edit) second edit and amend' '\n>  \tgit rebase --continue &&\n>  \tgit commit --amend -m \"h\" &&\n>  \tcat >expected <<-EOF &&\n> -\t# HEAD detached from $ONTO\n> +\t# Not currently on any branch.\n>  \t# You are currently editing a commit while rebasing branch '\\''several_edits'\\'' on '\\''$ONTO'\\''.\n>  \t#   (use \"git commit --amend\" to amend the current commit)\n>  \t#   (use \"git rebase --continue\" once you are satisfied with your changes)\n> diff --git a/wt-status.c b/wt-status.c\n> index 2511270..f7d46a1 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -1173,15 +1173,12 @@ void wt_status_print(struct wt_status *s)\n>  \t\tif (!prefixcmp(branch_name, \"refs/heads/\"))\n>  \t\t\tbranch_name += 11;\n>  \t\telse if (!strcmp(branch_name, \"HEAD\")) {\n> +\t\t\tunsigned char sha1[20];\n>  \t\t\tbranch_status_color = color(WT_STATUS_NOBRANCH, s);\n> -\t\t\tif (state.detached_from) {\n> -\t\t\t\tunsigned char sha1[20];\n> +\t\t\tif (state.detached_from && !get_sha1(\"HEAD\", sha1) &&\n> +\t\t\t\t!hashcmp(sha1, state.detached_sha1)) {\n>  \t\t\t\tbranch_name = state.detached_from;\n> -\t\t\t\tif (!get_sha1(\"HEAD\", sha1) &&\n> -\t\t\t\t    !hashcmp(sha1, state.detached_sha1))\n> -\t\t\t\t\ton_what = _(\"HEAD detached at \");\n> -\t\t\t\telse\n> -\t\t\t\t\ton_what = _(\"HEAD detached from \");\n> +\t\t\t\ton_what = _(\"HEAD detached at \");\n>  \t\t\t} else {\n>  \t\t\t\tbranch_name = \"\";\n>  \t\t\t\ton_what = _(\"Not currently on any branch.\");\n"},{"id":"220754","messageId":"CALkWK0=FLerEwaLzSbiT0fuBApgJFcH1eLfnLHQTCHFYvDm=DA@mail.gmail.com","threadId":"34124","inReplyTo":"7vvc5hubox.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T18:15:41Z","receivedAt":"2013-06-13T18:15:41Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> [...]\n\nI'd just like to point out quickly that I first attempted to write 6/6\nwithout this patch.  It is absolutely impossible, because the\n\"detached HEAD from/to\" messages no longer make any sense when\ncheckout starts respecting GIT_REFLOG_ACTION.  At that point, I'm was\njust monkeying around the trash-directory running describes to somehow\ntry and make the expected output equal to the actual output.  There\nwas no method to the madness, and I was literally losing my mind.\n\nThis is _the_ patch that makes this series possible.\n\nIf you want to be convinced, please attempt to drop this patch and fix\nthe tests in 6/6.  You will see what I mean.\n"},{"id":"220763","messageId":"CALkWK0nH5Qjc-PNNH0cAhsgZje7VzuLGqXZwjRQESOxLt-T78g@mail.gmail.com","threadId":"34124","inReplyTo":"7vfvwlvr7e.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/6] t/checkout-last: checkout - doesn't work after rebase","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T18:30:54Z","receivedAt":"2013-06-13T18:30:54Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Why two?\n\nWhat breaks checkout - is the initial HEAD detachment (which writes\nthat \"checkout: \" message), before anything else happens.  None of\n<onto>, <upstream>, and <branch> make any difference: I'm testing\nexactly the code that I patched.\n\nI have recently been told that I should be testing \"end-user behavior\"\nby treating the programs as black-boxes, instead of \"implementation\".\nWhat is your opinion on the issue?  Should I write more tests?\n"},{"id":"220765","messageId":"CALkWK0kjxKFkrLArL1mLZYCMN1=sgnDSa3vaoJm6eSUp2E4Pyw@mail.gmail.com","threadId":"34124","inReplyTo":"7vvc5hubox.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-13T18:48:44Z","receivedAt":"2013-06-13T18:48:44Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n>> At this point, the utility of such a message is in question.\n>\n> You can question, but I am not convinced the answer is an\n> unambiguous \"not useful\"\n\nI am not arguing for an unambiguous \"not useful\".  I am arguing for a\npractical compromise: this patch locks things up too tightly, and\nmakes life hell for contributors who want to improve reflog messages.\nTo be clear: the problem is not the feature, but rather in the\n_implementation_ of the feature.\n\n> You were at 1.8.2 but no longer are, so in the following sequence:\n>\n>     $ git checkout v1.8.2\n>     $ git status\n>     $ git reset --hard HEAD^\n>     $ git status\n>\n> the former would say \"detached at v1.8.2\" while the latter should\n> *not*, because we are no longer at v1.8.2.  \"detached from v1.8.2\"\n> is too subtle a way to express the state, and is confusing, but I\n> would not be surprised if people find it useful to be able to learn\n> \"v1.8.2\" even after you strayed away.\n\nWhat is wrong with git describe?  Is this cheaper, or am I missing something?\n\n>> Moreover,\n>> there are several tests in t/status-help that explicitly rely on rebase\n>> writing \"checkout: \" messages to the reflog.  As evidenced by the\n>> failing tests in t/checkout-last, these messages are completely\n>> unintended and flaky.\n>\n> The above only helps to convince me that \"rebase should not affect\n> what the last checked-out branch was by letting 'checkout' it\n> internally calls to write reflog entries for it\"  With patches 6, 2,\n> and 3, I thought you fixed that issue.\n\nI also thought of ignoring the first line in the actual output (\"HEAD\ndetached from/to\"), and comparing the rest to make the tests pass.  At\nthat point, you start to wonder: what is this fantastic feature that\nwe are bending over backwards for?\n"},{"id":"220768","messageId":"7vhah1u4o5.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0nH5Qjc-PNNH0cAhsgZje7VzuLGqXZwjRQESOxLt-T78g@mail.gmail.com","subject":"Re: [PATCH 1/6] t/checkout-last: checkout - doesn't work after rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-13T20:38:50Z","receivedAt":"2013-06-13T20:38:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> Why two?\n>\n> What breaks checkout - is the initial HEAD detachment (which writes\n> that \"checkout: \" message), before anything else happens.  None of\n> <onto>, <upstream>, and <branch> make any difference: I'm testing\n> exactly the code that I patched.\n>\n> I have recently been told that I should be testing \"end-user behavior\"\n> by treating the programs as black-boxes, instead of \"implementation\".\n> What is your opinion on the issue?  Should I write more tests?\n\nOf course, the behaviours that should be observable by end-users\nneed be spelled out.  Also, an impementation detail that cannot be\nobserved or make any difference to the end-user experience should\nnot be cast in stone.\n\nThe guideline is a good one, but you need to realize that there is a\ndifference between \"do not test implementation details\" and \"do not\nlook at implementation when designing tests\".  Only the former is\nnecessary and correct: it lets you avoid over-specifying the\nbehaviour.\n\nSometimes you can trivially tell that some obvious implementations\nthat may be different from what you have can break the expectation\nyou are setting.  For example, in v1.5.0, \"rebase A B\" literally ran\n\"git-checkout B\" as the first thing, and if you want the end-user to\nexpect that @{-$n} does not resolve to B because such internal\n\"checkout\" is not an user action, covering \"rebase A B\", even if you\nknow that the current implemention happens to be immune to such a\nform of breakage, would be a good way to future-proof your code.\n\nThat still is testing the behaviour.  You are just taking advantage\nof the fact that you know the implementation and can anticipate how\nfuture changes by careless people could break the behaviour.\n"},{"id":"220770","messageId":"7vd2rpu3kf.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0kjxKFkrLArL1mLZYCMN1=sgnDSa3vaoJm6eSUp2E4Pyw@mail.gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-13T21:02:40Z","receivedAt":"2013-06-13T21:02:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> To be clear: the problem is not the feature, but rather in the\n> _implementation_ of the feature.\n\nOK, but are we discussing the same \"feature\" (see below)?\n\n>> You were at 1.8.2 but no longer are, so in the following sequence:\n>>\n>>     $ git checkout v1.8.2\n>>     $ git status\n>>     $ git reset --hard HEAD^\n>>     $ git status\n>>\n>> the former would say \"detached at v1.8.2\" while the latter should\n>> *not*, because we are no longer at v1.8.2.  \"detached from v1.8.2\"\n>> is too subtle a way to express the state, and is confusing, but I\n>> would not be surprised if people find it useful to be able to learn\n>> \"v1.8.2\" even after you strayed away.\n>\n> What is wrong with git describe?  Is this cheaper, or am I missing something?\n\nI think what you are missing is that the \"detached from\" is not\nabout your current HEAD after you flipped it around with many resets\nand commits.  It is about what tag or what specific commit you\ndetached your HEAD at originally.\n\n\"You can ask the same to describe\" is wrong and is not a valid\nargument.  Once you replace the HEAD^ with a distant commit\n(e.g. HEAD~400) in the third step in the example, \"describe\" will\nnot talk about v1.8.2 at all.\n\nYour argument can be that it is not a useful piece of information,\nand as you can probably guess from my \"I wouldn't be surprised\"\nabove, I am not sure how useful it would be and in what situation\n[*1*].\n\nBut the original commit thought it was necessary and that was done\nfor a reason; we need to be careful here.  With a good justification\nwhy it is not necessary (or misleading to the user), I do not think\nwe cannot change it.\n\nAs various tools that use detached \"intermediate\" states leave\nenough clues for \"status\" to notice what is going on, I actually\nthink it is a mistake to focus on what happens when we are in such a\ndetached \"intermediate\" status with this codepath.  For example:\n\n\t$ git rebase master\n        ... replays some but stops\n        $ git status\n\ncurrently uses that \"HEAD detached from\" codepath, but I think that\nis a mistake.  We could not just tell the HEAD is detached, but the\nreason _why_ the HEAD is detached (i.e. we are in the middle of a\nrebase).  The prompt script can do it, \"status\" should be able to do\nthe same, and do a lot more sensible thing than unconditionally\nshowing that \"HEAD detached from\" and then say \"You are currently\nrebasing\" on a separate line.  Most likely we do not want to even\nsay \"Not currently on any branch\" but just say \"You are currently\nrebasing branch X on top of Y\" (and perhaps \"N commits remaining to\nbe replayed\").\n\n\n[Footnote]\n\n*1* One thing I could think of is to start sightseeing or (more\n    realistically) manually bisecting at a given release point,\n    reset the detached HEAD around several times, and then want to\n    be reminded where the session started from.  I do not think it\n    is particularly a very good example, though.\n"},{"id":"220782","messageId":"CALkWK0=NAiGDVWbwHXMmEffPF9wKXd23BdwOntfdvNCpVe8fiA@mail.gmail.com","threadId":"34124","inReplyTo":"7vd2rpu3kf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-14T06:27:14Z","receivedAt":"2013-06-14T06:27:14Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n>> What is wrong with git describe?  Is this cheaper, or am I missing something?\n>\n> I think what you are missing is that the \"detached from\" is not\n> about your current HEAD after you flipped it around with many resets\n> and commits.  It is about what tag or what specific commit you\n> detached your HEAD at originally.\n\nNo, it is about what tag of specific commit you detached your HEAD\nfrom, *without using checkout*.  If you used checkout, you'd get the\n\"detached at\" message, and I haven't changed that.\n\n> \"You can ask the same to describe\" is wrong and is not a valid\n> argument.  Once you replace the HEAD^ with a distant commit\n> (e.g. HEAD~400) in the third step in the example, \"describe\" will\n> not talk about v1.8.2 at all.\n\nYou're missing the point: how do I, as the end-user, detach my HEAD\n*without using checkout*?  The hypothetical example you have given is:\n\n  $ git checkout HEAD^\n  $ git update-ref HEAD $(git rev-parse HEAD~400)\n\nWhich end-user executes that?\n\n> Your argument can be that it is not a useful piece of information,\n> and as you can probably guess from my \"I wouldn't be surprised\"\n> above, I am not sure how useful it would be and in what situation\n> [*1*].\n\nPrecisely.  It is a poorly thought-out feature that locks things up\ntoo tightly, and makes life hell for contributors.  It must therefore\nbe removed.\n\n> But the original commit thought it was necessary and that was done\n> for a reason; we need to be careful here.  With a good justification\n> why it is not necessary (or misleading to the user), I do not think\n> we cannot change it.\n\nWe cannot reverse-engineer intents.  All we can do is look at the\nevidence in front of us.  Read the commit message, and look at the\nnewly added test.  There is absolutely no indication about why this\n\"detached from\" is useful, and where.\n\n>         $ git rebase master\n>         ... replays some but stops\n>         $ git status\n>\n> currently uses that \"HEAD detached from\" codepath, but I think that\n> is a mistake.  We could not just tell the HEAD is detached, but the\n> reason _why_ the HEAD is detached (i.e. we are in the middle of a\n> rebase).  The prompt script can do it, \"status\" should be able to do\n> the same, and do a lot more sensible thing than unconditionally\n> showing that \"HEAD detached from\" and then say \"You are currently\n> rebasing\" on a separate line.  Most likely we do not want to even\n> say \"Not currently on any branch\" but just say \"You are currently\n> rebasing branch X on top of Y\" (and perhaps \"N commits remaining to\n> be replayed\").\n\nThat information is available in .git/{rebase-apply,rebase-merge}, and\nyour suggestion pertains to improving show_rebase_in_progress().  The\nfirst line is about the state of HEAD, and is completely orthogonal to\nthe issue at hand.\n\n  artagnon|rebase-rev-failure|REBASE-i 2/3:~/src/git$ git status\n  # HEAD detached from a7e9fd4\n  # You are currently editing a commit while rebasing branch\n'rebase-rev-failure' on '9926f66'.\n  #\n  nothing to commit, working directory clean\n\nThat first line about \"HEAD detached from ...\" is completely useless.\nAnd yes, my prompt is more useful.  No prizes for guessing how often I\nuse the long form of git status.\n\n> *1* One thing I could think of is to start sightseeing or (more\n>     realistically) manually bisecting at a given release point,\n>     reset the detached HEAD around several times, and then want to\n>     be reminded where the session started from.  I do not think it\n>     is particularly a very good example, though.\n\nThe example you have given now is:\n\n  $ git checkout @^\n  # or whatever bisect command to detach HEAD\n  $ git reset @~3\n  ...\n  $ git reset @^\n  ...\n  $ git reset @~5\n  ....\n  # when was HEAD originally detached?\n\nYes, it is a contrived example where this feature arguably has some\nutility.  Is it worth putting the information in the status for such\nan esoteric example?  If one really wants this information, they can\nopen up the reflog and grep for \"checkout: \".\n"},{"id":"220849","messageId":"7vppvosstl.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0=NAiGDVWbwHXMmEffPF9wKXd23BdwOntfdvNCpVe8fiA@mail.gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-14T13:52:22Z","receivedAt":"2013-06-14T13:52:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>>> What is wrong with git describe?  Is this cheaper, or am I missing something?\n>>\n>> I think what you are missing is that the \"detached from\" is not\n>> about your current HEAD after you flipped it around with many resets\n>> and commits.  It is about what tag or what specific commit you\n>> detached your HEAD at originally.\n>\n> No, it is about what tag of specific commit you detached your HEAD\n> from, *without using checkout*.  If you used checkout, you'd get the\n> \"detached at\" message, and I haven't changed that.\n\nThe part you stripped from your quote looked like this:\n\n>> You were at 1.8.2 but no longer are, so in the following sequence:\n>>\n>>     $ git checkout v1.8.2\n>>     $ git status\n>>     $ git reset --hard HEAD^\n>>     $ git status\n>>\n>> the former would say \"detached at v1.8.2\" while the latter should\n>> *not*, because we are no longer at v1.8.2.  \"detached from v1.8.2\"\n>> is too subtle a way to express the state, and is confusing, but I\n>> would not be surprised if people find it useful to be able to learn\n>> \"v1.8.2\" even after you strayed away.\n\nAnd your justification to make the latter \"git status\" to say \"Not\non any branch\" instead of \"detached from\" was \"what is wrong with\ndescribe\".\n\nThe user used \"checkout\" to detach the HEAD, and the user stayed in\nthat detached state and jumped around.  Where is this \"without using\ncheckout\" coming from?\n"},{"id":"220866","messageId":"CALkWK0k28u583Jci+Dvad1pbu7_dJdnmz1WBkP790a_t2QdPTg@mail.gmail.com","threadId":"34124","inReplyTo":"7vppvosstl.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-14T14:01:30Z","receivedAt":"2013-06-14T14:01:30Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> The part you stripped from your quote looked like this:\n\nApologies for the lack of clarity.\n\n>>> You were at 1.8.2 but no longer are, so in the following sequence:\n>>>\n>>>     $ git checkout v1.8.2\n>>>     $ git status\n>>>     $ git reset --hard HEAD^\n>>>     $ git status\n>>>\n>>> the former would say \"detached at v1.8.2\" while the latter should\n>>> *not*, because we are no longer at v1.8.2.  \"detached from v1.8.2\"\n>>> is too subtle a way to express the state, and is confusing, but I\n>>> would not be surprised if people find it useful to be able to learn\n>>> \"v1.8.2\" even after you strayed away.\n>\n> And your justification to make the latter \"git status\" to say \"Not\n> on any branch\" instead of \"detached from\" was \"what is wrong with\n> describe\".\n\nIn this example, it is inconsequential whether I run:\n\n  $ git checkout v1.8.2^\n\nor:\n\n  $ git checkout v1.8.2\n  $ git reset --hard @^\n\nas far as describe is concerned.  It will give me the same good\nconsistent answer in either case.\n\n> The user used \"checkout\" to detach the HEAD, and the user stayed in\n> that detached state and jumped around.  Where is this \"without using\n> checkout\" coming from?\n\nThe point I was trying to make is:\n\n  $ git checkout v1.8.2\n  $ git checkout @^\n\nwill give a different result once again.  As the end-user, I use\ncheckout to inspect detached HEAD states, and reset to update\nworktree/refs.\n\nDid my response to your examples make sense?  Are you convinced that\nthis feature should be removed yet?\n"},{"id":"220868","messageId":"7v38sksq14.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0k28u583Jci+Dvad1pbu7_dJdnmz1WBkP790a_t2QdPTg@mail.gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-14T14:52:39Z","receivedAt":"2013-06-14T14:52:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> In this example, it is inconsequential whether I run:\n>\n>   $ git checkout v1.8.2^\n>\n> or:\n>\n>   $ git checkout v1.8.2\n>   $ git reset --hard @^\n>\n> as far as describe is concerned.  It will give me the same good\n> consistent answer in either case.\n\nYes, \"describe HEAD\" is about the location in the history of the\ncommit at the current HEAD.\n\nBut the commit shown on \"detached at/detached from\" is for people\nwho care about the differences between the initial \"checkout\" you\ndid in these two examples: \"checkout v1.8.2^\" and \"checkout v1.8.2\".\n\nThat is different from the question you ask to \"describe\", which is\nthe location your HEAD happens to be in the commit ancestry graph\nafter you detached the HEAD with \"checkout\" and possibly jumping\naround.  If you say \"Not on any branch\" instead of saying \"detached\nfrom v1.8.2\" (or v1.8.2^), you are losing information, aren't you?\n\nAs I said (twice), you can argue that that particular piece of\ninformation is not useful (at least to you), but why it is not\nuseful has to be justified, against the justification given by\nb397ea4863a1 (status: show more info than \"currently not on any\nbranch\", 2013-03-13) and people who have been using that information\nin the status output, no?\n\n>> The user used \"checkout\" to detach the HEAD, and the user stayed in\n>> that detached state and jumped around.  Where is this \"without using\n>> checkout\" coming from?\n>\n> The point I was trying to make is:\n>\n>   $ git checkout v1.8.2\n>   $ git checkout @^\n>\n> will give a different result once again.\n\nThe last checkout is for HEAD^ while at v1.8.2 in this case, isn't\nit?  Don't you want to show it?\n"},{"id":"220873","messageId":"CALkWK0n_Jsb46qPojbGL3S+mPunNQWUOmypQOvdaBjcT5wgJBg@mail.gmail.com","threadId":"34124","inReplyTo":"7v38sksq14.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-14T15:08:10Z","receivedAt":"2013-06-14T15:08:10Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> As I said (twice), you can argue that that particular piece of\n> information is not useful (at least to you), but why it is not\n> useful has to be justified, against the justification given by\n> b397ea4863a1 (status: show more info than \"currently not on any\n> branch\", 2013-03-13) and people who have been using that information\n> in the status output, no?\n\nYes, Junio.  I cannot justify that \"detached HEAD from\" is completely\nuseless, because it is not.  I argued for a practical compromise, and\nhave tried to show the huge negative impact against the marginal gain.\n If you argue that we absolutely must not cause an\ninformation-regression against all odds and are unwilling to\ncompromise, I cannot improve the reflog messages written by various\nscripts (and fix git checkout -).  I don't know any other way forward.\n"},{"id":"220889","messageId":"7vsj0kpsb0.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0n_Jsb46qPojbGL3S+mPunNQWUOmypQOvdaBjcT5wgJBg@mail.gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-14T16:31:47Z","receivedAt":"2013-06-14T16:31:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> As I said (twice), you can argue that that particular piece of\n>> information is not useful (at least to you), but why it is not\n>> useful has to be justified, against the justification given by\n>> b397ea4863a1 (status: show more info than \"currently not on any\n>> branch\", 2013-03-13) and people who have been using that information\n>> in the status output, no?\n>\n> Yes, Junio.  I cannot justify that \"detached HEAD from\" is completely\n> useless, because it is not.  I argued for a practical compromise, and\n> have tried to show the huge negative impact against the marginal gain.\n\nFirst of all, during a stopped \"git rebase\", I think \"git status\"\nthat says \"# HEAD detached at\" or \"# HEAD detached from\" is not\nsomething we want in the end result anyway.  In either case, that\ncomes from the internal use of \"git checkout\" by the command to\nswitch out of a concrete branch, which is *not* user initiated.\n\nIf you first update \"git checkout\" so that it will pay attention to\na custom reflog-action exported by Porcelain scripts that may want\nto internally use it to flip branches (and without a custom one, it\nwill still record \"checkout: moving from A to B\"), without exporting\ncustom reflog-action from \"rebase\" and other Porcelain scripts, that\nwould not affect any externally visible behaviour.\n\nWhen you teach \"git rebase\" to pass custom reflog-action when it\ndetaches the HEAD at \"$onto^0\" (because that is not a user-initiated\naction) as the next step, nth_prior_checkout and 1st_switch would\nstop counting them as \"checkout\" events.  That fix will give you the\ndesired result of the topic of this series, i.e. \"git checkout @{-1}\"\nignores the internal \"git checkout\" done by \"rebase\".\n\nThat step may change the output from \"git status\" but I do not think\nthe output from \"git status\" in this sequence:\n\n\tgit rebase ;# stops upon conflict\n        git status\n\nis anything sacred.  Tests modified by b397ea4863a1 (status: show\nmore info than \"currently not on any branch\", 2013-03-13) do change\nthe original \"# Not currently on any branch\" to \"detached at\", but I\ndo not think b397ea4863a1 _wanted_ to say where the $onto commit was\nduring the rebase (or was it?), so if they have to change to\n\"detached from\", I do not think it is a problem at all.  I think it\nis very sane to update these selected \"detached at\" to \"detached\nfrom\" as needed.\n\nThat would be a sensible compromise, because we do not want to see\neither \"detached at\" or \"detached from\" during \"rebase\" in the\nlonger term.  We would rather want to see the message start with\nsomething like\n\n\t# Rebasing X on top of Y (23 commits remaining to be replayed)\n\nwhich is under discussion in a separate thread lately.  The change\nto expected output (i.e. \"detached at\" to \"detached from\") will have\nto be changed again in that separate topic.\n\nThe very last test that the b397ea4863a1 added, which wants to see\n\"detached at atag\", should be kept, and also there should be another\ntest added to reset one step back to make sure we see \"detached\nfrom\" after it.  It tests what the user sees after a \"git checkout\"\ninitiated by the end-user.\n"},{"id":"220911","messageId":"CALkWK0==Phbe-9QaOa3jkYMEvxb6F3kypRkk9RbzrLco-HkHKw@mail.gmail.com","threadId":"34124","inReplyTo":"7vsj0kpsb0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-14T21:36:17Z","receivedAt":"2013-06-14T21:36:17Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> If you first update \"git checkout\" so that it will pay attention to\n> a custom reflog-action exported by Porcelain scripts that may want\n> to internally use it to flip branches (and without a custom one, it\n> will still record \"checkout: moving from A to B\"), without exporting\n> custom reflog-action from \"rebase\" and other Porcelain scripts, that\n> would not affect any externally visible behaviour.\n\nrebase already sets a custom reflog-action; in fact,\n'set_reflog_action rebase' is executed after it sources sh-setup.  I\nhave to go out of my way to deliberately unset it before every\ncheckout invocation to avoid breaking all the tests in t/status-help.\nMost unnatural way to go about writing a series, if you ask me.\n\n> Tests modified by b397ea4863a1 (status: show\n> more info than \"currently not on any branch\", 2013-03-13) do change\n> the original \"# Not currently on any branch\" to \"detached at\", but I\n> do not think b397ea4863a1 _wanted_ to say where the $onto commit was\n> during the rebase (or was it?), so if they have to change to\n> \"detached from\", I do not think it is a problem at all.  I think it\n> is very sane to update these selected \"detached at\" to \"detached\n> from\" as needed.\n\n... and you have missed the point yet again.\n\nI previously wrote:\n> I'd just like to point out quickly that I first attempted to write 6/6\n> without this patch.  It is absolutely impossible, because the\n> \"detached HEAD from/to\" messages no longer make any sense when\n> checkout starts respecting GIT_REFLOG_ACTION.  At that point, I'm was\n> just monkeying around the trash-directory running describes to somehow\n> try and make the expected output equal to the actual output.  There\n> was no method to the madness, and I was literally losing my mind.\n\nLet me try and explain this once again: to determine \"HEAD detached\nfrom/to\", wt-status must look for a previous \"checkout: \" message in\nthe reflog.  Since a rebase no longer executes a checkout, the\n\"detached HEAD from\" message no longer has anything to do with the\nrebase itself; it is completely _random_ and _incidental_, based on\nwhat checkout operation was executed last (eg. in a previous test).\nTo change the \"detached HEAD to\" messages to \"detached HEAD from\"\nmessages, I have to turn myself into a monkey that goes around running\ndescribes on the test-directory.  After enduring hours of this\nmind-numbing job, the final result will be a terrible mess; tests can\nno longer be added, removed, reordered, or even tweaked.  Everything\ndepends on the exact ordering of the tests, and the incidental\ncheckout invocations they contain.\n\n> That would be a sensible compromise\n\nHow is it a compromise?  It is most uncompromising.\n\n> because we do not want to see\n> either \"detached at\" or \"detached from\" during \"rebase\" in the\n> longer term.  We would rather want to see the message start with\n> something like\n>\n>         # Rebasing X on top of Y (23 commits remaining to be replayed)\n>\n> which is under discussion in a separate thread lately.  The change\n> to expected output (i.e. \"detached at\" to \"detached from\") will have\n> to be changed again in that separate topic.\n\nOrthogonal.  I want checkout-dash now, and I should not have to be\nasked to do something as unrelated as redoing 'git status' output to\nget what I want.\n\nSince you have made it clear that you will defend every bit of b397ea\nagainst all odds, and since I want checkout-dash now, we have to do\nsomething.  I have a proposal: I will smudge the first line of the\n'git status' output, before comparing it to make tests pass.  Never\nmind that the line is incidental and Wrong; since I have no say in the\nmatter, I will just sidestep the issue.  I don't use the long-form\n'git status' anyway, and am never going to see this ugliness.  We both\nwin.  Okay?\n"},{"id":"220921","messageId":"7vfvwkmj7x.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0==Phbe-9QaOa3jkYMEvxb6F3kypRkk9RbzrLco-HkHKw@mail.gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-14T22:16:18Z","receivedAt":"2013-06-14T22:16:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> If you first update \"git checkout\" so that it will pay attention to\n>> a custom reflog-action exported by Porcelain scripts that may want\n>> to internally use it to flip branches (and without a custom one, it\n>> will still record \"checkout: moving from A to B\"), without exporting\n>> custom reflog-action from \"rebase\" and other Porcelain scripts, that\n>> would not affect any externally visible behaviour.\n>\n> rebase already sets a custom reflog-action; in fact,\n> 'set_reflog_action rebase' is executed after it sources sh-setup.\n\nAh, OK, that is what I missed, so updating the \"checkout\" itself\nwill affect the test Duy's commit updated.\n\nBut that does not change anything.  The thing is, I fully agree with\nthis:\n\n> the \"detached HEAD from\" message no longer has anything to do with\n> the rebase itself; it is completely _random_ and _incidental_.\n\nbecause at the end of this series, we will not be recording the\ninternal \"checkout\" as a checkout event in the reflog.\nWhat the top-line of \"git status\" says does not matter.\n\nIf I were doing this series, the first commit before doing anything\nelse would be to strip that line from the expected output from \"git\nstatus\" for tests Duy's commit changed, with the justification\nperhaps like this:\n\n    b397ea4863a1 (status: show more info than \"currently not on any\n    branch\", 2013-03-13) wanted to make sure that after a checkout\n    to detach HEAD, the user can see where the HEAD was originally\n    detached from.\n\n    The last test added by that commit to t7512 shows one example,\n    immediately after HEAD is detached.  Add another test to show\n    \"detached HEAD from\" form that should be shown when the user\n    further resetted to another commit.\n\n    The majority of tests in t7512 that commit updated, however, are\n    looking at the status output while in \"rebase\", and the exact\n    content of that first line relies on the fact that \"git rebase\"\n    used \"git checkout\" to first detach HEAD before doing anything\n    else, and allowed that to be recorded in the reflog just like a\n    user initiated \"checkout\".  As far as the user is concerned,\n    however, this operation is not a \"checkout\" that the user would\n    want to count when later issuing \"git checkout @{-1}\", etc.\n\n    We are going to fix \"git rebase\" not to let reflog record these\n    internal events as \"checkout\"; these first lines will start\n    saying different (and useless) things.  Improving them to give\n    a message more appropriate during \"rebase\" (e.g. \"# Rebasing\n    branch X on top of Y\", instead of \"# Not currently on any\n    branch\" or \"# HEAD detached from Z\") is left to a separate\n    future series, but until that happens, stop checking what\n    appears on that first line.\n\nand would keep the last one that shows \"detached HEAD at\".  That is\nwhat that commit wantd to achieve.  This first commit in the series\nwould be a good place to add the missing one after that to show\n\"detached HEAD from\", doing \"reset HEAD^\".  In other words, we can\nmake this tirst step as a pure clean-up.\n\nIf stripping the first line to compare is too much, then I think it\nis an acceptable compromise to update the \"# HEAD detached from\n$ONTO\" Duy's patch changed from \"# Not currently on ...\" to whatever\nyour updated \"rebase\" happens to produce, with the same (but weaker)\njustification as the last sentence in my \"perhaps like this\" above.\n"},{"id":"220924","messageId":"7v7ghwmi9x.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0==Phbe-9QaOa3jkYMEvxb6F3kypRkk9RbzrLco-HkHKw@mail.gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-14T22:36:42Z","receivedAt":"2013-06-14T22:36:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Since you have made it clear that you will defend every bit of b397ea\n\nYou are misreading me.  I am not defending every bit at all.\n\nWe both agree that what b397ea4863a1 (status: show more info than\n\"currently not on any branch\", 2013-03-13) expects from \"git status\"\nduring an interrupted \"git rebase\" is _not_ sacred, especially when\nwe are about to fix what \"git rebase\" records in the reflog.\n\nI am only saying that the last test the commit adds must be kept\nunbroken.  I am also saying that, even though that commit did not\nadd a test for \"detached from\" case, we should add something like\nthe attached to protect the behaviour.  These two are sacred.\n\nWhat happens to be shown during a stopped \"git rebase\" is not.\n\nI have been assuming the \"main\" thing Duy wanted to do was the last\ntest (and the one below), but was this meant as an improvement for\n\"git status\" output during that state?  Showing $ONTO certainly\nmakes some sense, and from that point of view, the change we are\ndiscussing _will_ be a regression if it just shows a random thing.\nIf you want to avoid regression, the codepath in wt-status.c should\ncompensate for the change to \"rebase\" so that it checks $dotest/onto\nand show what is recorded in there.\n\nBut in practice, as far as we know other people are working on it in\nthe near-by thread, I do not think this particular regression (if it\nwas) matters that much.  At the worst, we can queue that on top of\nthis topic to fix \"rebase ; checkout -\" and have them graduate at\nthe same time to avoid it.\n\n t/t7512-status-help.sh | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh\nindex bf08d4e..e07185e 100755\n--- a/t/t7512-status-help.sh\n+++ b/t/t7512-status-help.sh\n@@ -675,6 +675,14 @@ test_expect_success 'status showing detached from a tag' '\n \tnothing to commit (use -u to show untracked files)\n \tEOF\n \tgit status --untracked-files=no >actual &&\n+\ttest_i18ncmp expected actual &&\n+\n+\tgit reset --hard HEAD^ &&\n+\tcat >expected <<-\\EOF\n+\t# HEAD detached from atag\n+\tnothing to commit (use -u to show untracked files)\n+\tEOF\n+\tgit status --untracked-files=no >actual &&\n \ttest_i18ncmp expected actual\n '\n \n"},{"id":"220925","messageId":"7v38skmgu8.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"7v7ghwmi9x.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-14T23:07:43Z","receivedAt":"2013-06-14T23:07:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I have been assuming the \"main\" thing Duy wanted to do was the last\n> test (and the one below), but was this meant as an improvement for\n> \"git status\" output during that state?  Showing $ONTO certainly\n> makes some sense, and from that point of view, the change we are\n> discussing _will_ be a regression if it just shows a random thing.\n>\n> If you want to avoid regression, the codepath in wt-status.c should\n> compensate for the change to \"rebase\" so that it checks $dotest/onto\n> and show what is recorded in there.\n\nAnd it might be just the matter of doing something like this\n(totally untested, of course).  Then the people who want to improve\n\"status\" to give more detailed state during \"rebase\" can further\nenhance the logic in this part to give more detailed information.\n\nI have a feeling that without changing anything in t7512 but\napplying the change to commit.c in your [6/6], most tests in there\nwould still pass, and you may even uncover latent *bug* that\nexpected to show a wrong $ONTO value in \"# HEAD detached from/at\"\nline.\n\n wt-status.c | 6 +++++-\n 1 file changed, 5 insertions(+), 1 deletion(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex bf84a86..403d48d 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -1176,7 +1176,11 @@ void wt_status_print(struct wt_status *s)\n \t\t\tbranch_name += 11;\n \t\telse if (!strcmp(branch_name, \"HEAD\")) {\n \t\t\tbranch_status_color = color(WT_STATUS_NOBRANCH, s);\n-\t\t\tif (state.detached_from) {\n+\n+\t\t\tif (state.rebase_in_progress) {\n+\t\t\t\ton_what = _(\"HEAD detached at \");\n+\t\t\t\tbranch_name = state.onto;\n+\t\t\t} else if (state.detached_from) {\n \t\t\t\tunsigned char sha1[20];\n \t\t\t\tbranch_name = state.detached_from;\n \t\t\t\tif (!get_sha1(\"HEAD\", sha1) &&\n"},{"id":"220928","messageId":"CALkWK0mCK_-bUapAvcrwtNgGnT1=x1d=+J9RO1GK6ssHWP2ztA@mail.gmail.com","threadId":"34124","inReplyTo":"7v38skmgu8.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-15T08:02:51Z","receivedAt":"2013-06-15T08:02:51Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n>  wt-status.c | 6 +++++-\n>  1 file changed, 5 insertions(+), 1 deletion(-)\n>\n> diff --git a/wt-status.c b/wt-status.c\n> index bf84a86..403d48d 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -1176,7 +1176,11 @@ void wt_status_print(struct wt_status *s)\n>                         branch_name += 11;\n>                 else if (!strcmp(branch_name, \"HEAD\")) {\n>                         branch_status_color = color(WT_STATUS_NOBRANCH, s);\n> -                       if (state.detached_from) {\n> +\n> +                       if (state.rebase_in_progress) {\n> +                               on_what = _(\"HEAD detached at \");\n> +                               branch_name = state.onto;\n> +                       } else if (state.detached_from) {\n>                                 unsigned char sha1[20];\n>                                 branch_name = state.detached_from;\n\nGood.  You have proposed a solution to the problem.  However, it is\nwrong for the following reasons:\n\n1. It shows a pseudo \"HEAD detached at\" message.  Everywhere else,\nwhen the user sees a \"HEAD detached at $committish\" message, git\nrev-parse $committish = git rev-parse HEAD.  A rebase-in-progress\nseems to be the only exception, and the user has no idea this is\nhappened.\n\n2. The following no longer updates status:\n\n  # in the middle of a rebase\n  $ git reset @~2\n\nThe constant \"HEAD detached at $onto\" message is misleading and Bad.\nBesides, wasn't this the primary usecase you wanted?\n\nYou previously wrote:\n> *1* One thing I could think of is to start sightseeing or (more\n>     realistically) manually bisecting at a given release point,\n>     reset the detached HEAD around several times, and then want to\n>     be reminded where the session started from.  I do not think it\n>     is particularly a very good example, though.\n\nWhether the HEAD is detached by bisect or rebase is irrelevant.\n\n3. The problem is not unique to rebase at all; yet you have\nspecial-cased it.  If this isn't a band-aid, what is?  The larger\nproblem, as I have stated previously, is that 'git status' output\ndepends on the _implementations_ of various commands (do they write a\n\"checkout: \" message to the reflog or not?).  Therefore, a future\ncontributor who updates a command to write more sensible reflog\nmessages will have to apply a similar band-aid.\n\nIf you want to take the band-aid approach, I think this is the right\nway to do it:\n\ndiff --git a/wt-status.c b/wt-status.c\nindex bf84a86..99c55e3 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -1182,7 +1182,7 @@ void wt_status_print(struct wt_status *s)\n \t\t\t\tif (!get_sha1(\"HEAD\", sha1) &&\n \t\t\t\t    !hashcmp(sha1, state.detached_sha1))\n \t\t\t\t\ton_what = _(\"HEAD detached at \");\n-\t\t\t\telse\n+\t\t\t\telse if (!state.rebase_in_progress)\n \t\t\t\t\ton_what = _(\"HEAD detached from \");\n \t\t\t} else {\n \t\t\t\tbranch_name = \"\";\n\nYou have already mentioned that there is a topic cooking to improve\nthis first-line in the case of rebase, so this regression from a\nsenseless message isn't a problem.\n\nThe problem with this bad-aid, as with all band aids, is that this\nwill soon explode to become else if(!state.rebase_in_progress &&\n!state.bisect_in_progress && ....) when people update those scripts.\nIf you don't want to go with the band-aid, I have no choice but to\nsmudge the first-line.\n"},{"id":"220929","messageId":"CALkWK0nDwqqiAq044wwj__1XzAuFDBUG59_0zHRMNzQ6ARsiww@mail.gmail.com","threadId":"34124","inReplyTo":"7v7ghwmi9x.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-15T08:44:56Z","receivedAt":"2013-06-15T08:44:56Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> I am only saying that the last test the commit adds must be kept\n> unbroken.  I am also saying that, even though that commit did not\n> add a test for \"detached from\" case, we should add something like\n> the attached to protect the behaviour.  These two are sacred.\n>\n> What happens to be shown during a stopped \"git rebase\" is not.\n>\n> I have been assuming the \"main\" thing Duy wanted to do was the last\n> test (and the one below), but was this meant as an improvement for\n> \"git status\" output during that state?\n\nOn what basis are you making that assumption?  b397ea4 did not add a\ntest for \"detached HEAD from\", and there is no evidence of what the\nauthor wanted in the commit message.  What has happened has happened;\nthe question is: what do _you_ want now?\n\nRead the various \"HEAD detached from/to\" messages in the rebase tests\nin t/status-help and tell me that they make some sense.  It does _not_\nshow a constant \"HEAD detached from $onto\", contrary to your\nassumption (evidenced by your patch in the later email).  Look at these\nhunk added by b397ea4, and tell me that it's not a monkey-patch:\n\n@@ -187,9 +187,10 @@ test_expect_success 'status when rebasing -i in\nedit mode' '\n        export FAKE_LINES &&\n        test_when_finished \"git rebase --abort\" &&\n        ONTO=$(git rev-parse --short HEAD~2) &&\n+       TGT=$(git rev-parse --short two_rebase_i) &&\n        git rebase -i HEAD~2 &&\n        cat >expected <<-EOF &&\n-       # Not currently on any branch.\n+       # HEAD detached from $TGT\n        # You are currently editing a commit while rebasing branch\n'\\''rebase_i_edit'\\'' on '\\''$ONTO'\\''.\n        #   (use \"git commit --amend\" to amend the current commit)\n        #   (use \"git rebase --continue\" once you are satisfied with\nyour changes)\n@@ -214,8 +215,9 @@ test_expect_success 'status when splitting a commit' '\n        ONTO=$(git rev-parse --short HEAD~3) &&\n        git rebase -i HEAD~3 &&\n        git reset HEAD^ &&\n+       TGT=$(git rev-parse --short HEAD) &&\n        cat >expected <<-EOF &&\n-       # Not currently on any branch.\n+       # HEAD detached at $TGT\n        # You are currently splitting a commit while rebasing branch\n'\\''split_commit'\\'' on '\\''$ONTO'\\''.\n        #   (Once your working directory is clean, run \"git rebase --continue\")\n        #\n@@ -243,10 +245,11 @@ test_expect_success 'status after editing the\nlast commit with --amend during a\n        export FAKE_LINES &&\n        test_when_finished \"git rebase --abort\" &&\n        ONTO=$(git rev-parse --short HEAD~3) &&\n+       TGT=$(git rev-parse --short three_amend) &&\n        git rebase -i HEAD~3 &&\n        git commit --amend -m \"foo\" &&\n        cat >expected <<-EOF &&\n-       # Not currently on any branch.\n+       # HEAD detached from $TGT\n        # You are currently editing a commit while rebasing branch\n'\\''amend_last'\\'' on '\\''$ONTO'\\''.\n        #   (use \"git commit --amend\" to amend the current commit)\n        #   (use \"git rebase --continue\" once you are satisfied with\nyour changes)\n\n\n> Showing $ONTO certainly\n> makes some sense, and from that point of view, the change we are\n> discussing _will_ be a regression if it just shows a random thing.\n\nIf showing $ONTO were the intent of the patch, this is no way to go\nabout it.  Reliable information is readily available in\n.git/rebase-apply; no parsing is required, and it is ready for\nconsumption.\n\nYour argument now is: because the patch _incidentally_ shows $ONTO in\nmany cases (as evidenced by the hunks above), the objective of the\npatch _must_ have been to show $ONTO.  Should I laugh or cry?\n\n> If you want to avoid regression, the codepath in wt-status.c should\n> compensate for the change to \"rebase\" so that it checks $dotest/onto\n> and show what is recorded in there.\n\nNow you want to achieve the exact same accidental behavior after\npatching rebase/checkout.  This is a never-ending nightmare.\n\n> You are misreading me.  I am not defending every bit at all.\n\nI am not misreading anything.  Despite me having repeatedly shown that\nb397ea4 is poorly done with far-reaching unintended consequences, you\nare unwilling to admit it.  Instead, you are trying to somehow\npreserve this accidental behavior.  And you still haven't been able to\nshow me how to do that.  As a result, checkout-dash is stalled.\n"},{"id":"220930","messageId":"7vsj0jln23.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0nDwqqiAq044wwj__1XzAuFDBUG59_0zHRMNzQ6ARsiww@mail.gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-15T09:51:00Z","receivedAt":"2013-06-15T09:51:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> I am only saying that the last test the commit adds must be kept\n>> unbroken.  I am also saying that, even though that commit did not\n>> add a test for \"detached from\" case, we should add something like\n>> the attached to protect the behaviour.  These two are sacred.\n>>\n>> What happens to be shown during a stopped \"git rebase\" is not.\n> ...\n> The question is: what do _you_ want now?\n\nIt should be fairly clear what _I_ want now.  Re-read the first four\nlines you quoted above.\n\n> Read the various \"HEAD detached from/to\" messages in the rebase tests\n> in t/status-help and tell me that they make some sense.\n\nAgain, re-read the part you did _not_ quote before those four lines.\nI do not think all of them make lot of sense; some of them may.\n\nUnless you are also tackling the topic of the other thread:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/227432/focus=227469\n\n(which I would not suggest to do in this topic), what these lines\nsay during \"rebase\" does not really matter, as far as your topic is\nconcerned.\n\nTwo possibilities:\n\n (1) Assume that the other thread will produce a more reasonable\n     semantics when finished; perhaps the first line will go away\n     entirely, or maybe it would say something like \"# Rebasing;\n     head at $commit\".\n\n     Your topic does not _care_ what it would say, so you tweak the\n     \"status\" test that is done during \"rebase\" so that they\n     ignore the first lines; or\n\n (2) Starting from the same assumption as above, but try to minimize\n     the semantics change to user-visible behaviour this series\n     makes.\n\n     That means that even though the _primary_ thing you want to do\n     is to tweak \"rebase\" and its internal use of \"checkout\" in such\n     a way that reflog will not record the implementation-detail\n     checkout (because that will affect the next \"checkout -\"), make\n     sure that \"status\" while doing \"rebase\" reports where the\n     internal \"checkout\" of $ONTO detached HEAD from/at.\n\nThe \"something along this line\" patch was an illustration of how\nthe beginning of the effort for (2) would look like.\n\nAs I already said, I could see us going either way.  If we can do\n(2), that may be better, but at end it would not matter that much as\nlong as we will be doing the other topic, too.\n"},{"id":"220931","messageId":"7vobb7lmpi.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0mCK_-bUapAvcrwtNgGnT1=x1d=+J9RO1GK6ssHWP2ztA@mail.gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-15T09:58:33Z","receivedAt":"2013-06-15T09:58:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> 2. The following no longer updates status:\n>\n>   # in the middle of a rebase\n>   $ git reset @~2\n>\n> The constant \"HEAD detached at $onto\" message is misleading and Bad.\n> Besides, wasn't this the primary usecase you wanted?\n\nSee the other message.  The first line from status in the middle of\na rebase is secondary.  End-user initiated \"checkout\" to detach is\nthe primary thing.\n\n> You previously wrote:\n>> *1* One thing I could think of is to start sightseeing or (more\n>>     realistically) manually bisecting at a given release point,\n>>     reset the detached HEAD around several times, and then want to\n>>     be reminded where the session started from.  I do not think it\n>>     is particularly a very good example, though.\n>\n> Whether the HEAD is detached by bisect or rebase is irrelevant.\n\nYou read and reacted to \"bisect\" too literally and missed\n\"manually\".  The scenario I had in mind does _not_ use \"git bisect\"\ncommand, which may _internally_ run \"git checkout\" to detach, but\nfor exactly the same reason why you want to touch \"git rebase\" in\nthis series, its use of \"checkout\" should not count for the next\n\"checkout -\".\n\nThe sequence of \"manually bisecting\" is like\n\n\t$ git checkout v1.8.3\n        ... test\n        $ git status\n        $ git log --oneline --first-parent v1.8.2..$detached_from\n        ... pick a likely point\n        $ git reset --hard $that_point\n        ... go back to test further\n\nwhich I actually do fairly often, as I tend to know more about the\nlikely place something may have been broken than a mechanical \"split\nthe history into about the same number of commits\" bisection.\n\n> 3. The problem is not unique to rebase at all; yet you have\n> special-cased it.  If this isn't a band-aid, what is?\n\nIt is an illustration for approach (2) in the other message.\n\nIn the longer term, you would want richer status output for various\ndetached state, and that \"how about this\" patch shows where new code\nto support other cases should be added.\n"},{"id":"220933","messageId":"7vfvwjllfo.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0nDwqqiAq044wwj__1XzAuFDBUG59_0zHRMNzQ6ARsiww@mail.gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-15T10:26:03Z","receivedAt":"2013-06-15T10:26:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n>> I have been assuming the \"main\" thing Duy wanted to do was the last\n>> test (and the one below), but was this meant as an improvement for\n>> \"git status\" output during that state?\n>\n> On what basis are you making that assumption? \n\nList archive helps.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/217342/focus=217444\n\nNot just that single message, but a few messages in the discussion\nthat led to the design shows that we wanted both \"at\" and \"from\" to\nmean something sensible, when a \"checkout\" initiated by the end-user\ndetached HEAD and we are not on any branch, even after making\ncommits or doing resets.\n"},{"id":"220934","messageId":"CALkWK0=R8h0_FUYMUFQ_qGC1Lf_Xvu84qigznYUK5MtzP8usPQ@mail.gmail.com","threadId":"34124","inReplyTo":"7vsj0jln23.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-15T12:08:39Z","receivedAt":"2013-06-15T12:08:39Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Two possibilities:\n>\n>  (1) Assume that the other thread will produce a more reasonable\n>      semantics when finished; perhaps the first line will go away\n>      entirely, or maybe it would say something like \"# Rebasing;\n>      head at $commit\".\n>\n>      Your topic does not _care_ what it would say, so you tweak the\n>      \"status\" test that is done during \"rebase\" so that they\n>      ignore the first lines; or\n\nYou said you didn't want to regress to show senseless information, and\nI agreed with that.  What is wrong with the patch I showed in the\nprevious email?  Smudging is a bad hack, and must only be used as a\nlast resort: when an another topics updates status to say something\nsensible, it will have to unsmudge the tests.\n\ndiff --git a/wt-status.c b/wt-status.c\nindex bf84a86..99c55e3 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -1182,7 +1182,7 @@ void wt_status_print(struct wt_status *s)\n                                if (!get_sha1(\"HEAD\", sha1) &&\n                                    !hashcmp(sha1, state.detached_sha1))\n                                        on_what = _(\"HEAD detached at \");\n-                               else\n+                               else if (!state.rebase_in_progress)\n                                        on_what = _(\"HEAD detached from \");\n                        } else {\n                                branch_name = \"\";\n\n>  (2) Starting from the same assumption as above, but try to minimize\n>      the semantics change to user-visible behaviour this series\n>      makes.\n\nThe \"try to minimize\" is a somewhat admirable goal, but I have shown\nthat your midway solution is wrong.  Either dedicate a lot of time and\neffort towards improving status for rebase, or don't attempt it.\n\n>      That means that even though the _primary_ thing you want to do\n>      is to tweak \"rebase\" and its internal use of \"checkout\" in such\n>      a way that reflog will not record the implementation-detail\n>      checkout (because that will affect the next \"checkout -\"), make\n>      sure that \"status\" while doing \"rebase\" reports where the\n>      internal \"checkout\" of $ONTO detached HEAD from/at.\n\nUnless we change the first line drastically to say: \"rebase in\nprogress: rebasing onto $ONTO\" (or something), I don't think this\nmakes sense.  And if we were to do that, why not do it properly like\n\"rebase ($N/$M): onto $ONTO, upstream $UPSTREAM, branch $BRANCH\"?\nOther people on a different thread are already handling that, and I am\nnot interested.\n\nSo, you have three simple choices now:\n\n1. Accept the simple patch I proposed above.\n2. Propose an alternative patch quickly.  *Patch*.  No more English.\n3. Reject all patches, and leave me no choice but to smudge.\n\nWhich one is it going to be?\n"},{"id":"220935","messageId":"CALkWK0nho2SgK3sBibqvPJLhEQw=cSmX3rdQ5LiQTEQkMhRnoQ@mail.gmail.com","threadId":"34124","inReplyTo":"7vobb7lmpi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-15T12:13:24Z","receivedAt":"2013-06-15T12:13:24Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> The first line from status in the middle of\n> a rebase is secondary.  End-user initiated \"checkout\" to detach is\n> the primary thing.\n>\n>> 3. The problem is not unique to rebase at all; yet you have\n>> special-cased it.  If this isn't a band-aid, what is?\n>\n> It is an illustration for approach (2) in the other message.\n>\n> In the longer term, you would want richer status output for various\n> detached state, and that \"how about this\" patch shows where new code\n> to support other cases should be added.\n\nFine.  If that is what you want, we'll have to special-case every\nknown script-in-progress to stop writing the usual \"HEAD detached\nfrom\" message.  That'll leave out only the \"end-user cases\", where you\nargue that the message is helpful.\n"},{"id":"220980","messageId":"7vip1ek37o.fsf@alter.siamese.dyndns.org","threadId":"34124","inReplyTo":"CALkWK0=R8h0_FUYMUFQ_qGC1Lf_Xvu84qigznYUK5MtzP8usPQ@mail.gmail.com","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-16T05:57:15Z","receivedAt":"2013-06-16T05:57:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> Two possibilities:\n>>\n>>  (1) Assume that the other thread will produce a more reasonable\n>>      semantics when finished; perhaps the first line will go away\n>>      entirely, or maybe it would say something like \"# Rebasing;\n>>      head at $commit\".\n>>\n>>      Your topic does not _care_ what it would say, so you tweak the\n>>      \"status\" test that is done during \"rebase\" so that they\n>>      ignore the first lines; or\n>\n> You said you didn't want to regress to show senseless information,...\n\nGo back and read it again.\n\n    If you want to avoid regression, the codepath in wt-status.c\n    should compensate for the change to \"rebase\" so that it checks\n    $dotest/onto and show what is recorded in there.\n\n> I agreed with that.  What is wrong with the patch I showed in the\n> previous email?\n\nWhich previous?  My message you are responding to was a response to\nyour non-patch message, and tangling the In-reply-to backwards will\nreach your original patch.\n\nPuzzled....\n\n> Smudging is a bad hack, and must only be used as a\n> last resort: when an another topics updates status to say something\n> sensible, it will have to unsmudge the tests.\n\nYes. I just got an impression, from your incessant arguing, that you\nare resisting the \"ignore the top\" as \"extra work that is not\ninteresting to _me_\", while I was trying to see what is the best way\nto go forward for the _project_.\n\nHonestly, I didn't want to waste my time and was trying to come up\nwith a compromise, which would be a small regression to the tests\nthat we will need to fix with the other topic.  Because you already\nsaid that you are not interested in that topic, I was anticipating\nthat the work to polish the topic would be a lot easier than\nanything I would have to do with you in this topic, because others\nare a lot easier to collaborate with than you are, and that is where\nthat suggestion comes from.\n\n> diff --git a/wt-status.c b/wt-status.c\n> index bf84a86..99c55e3 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -1182,7 +1182,7 @@ void wt_status_print(struct wt_status *s)\n>                                 if (!get_sha1(\"HEAD\", sha1) &&\n>                                     !hashcmp(sha1, state.detached_sha1))\n>                                         on_what = _(\"HEAD detached at \");\n> -                               else\n> +                               else if (!state.rebase_in_progress)\n>                                         on_what = _(\"HEAD detached from \");\n\nIs this supposed to be on top of your original patch?\n\nThe primary reason I suggested to special case \"rebase-in-progress\"\nin the \"how about this\" patch was because that way, you can have the\n\"have builtin/commit.c honor reflog-action\" much earlier in the\nseries, because what this part of the code would say will not be\naffected by what is recorded in the reflog.  If the above, together\nwith the original patch, makes the code match the expectation of the\n\"rebase stops in the middle and then status runs\" tests, that's also\nfine.  The other topic needs to redo it in either case anyway.\n\n> Unless we change the first line drastically to say: \"rebase in\n> progress: rebasing onto $ONTO\" (or something), I don't think this\n> makes sense.  And if we were to do that, why not do it properly like\n> \"rebase ($N/$M): onto $ONTO, upstream $UPSTREAM, branch $BRANCH\"?\n> Other people on a different thread are already handling that,...\n\nThat is the thread I was referring to.\n\n\n>\n> So, you have three simple choices now:\n>\n> 1. Accept the simple patch I proposed above.\n> 2. Propose an alternative patch quickly.  *Patch*.  No more English.\n> 3. Reject all patches, and leave me no choice but to smudge.\n>\n> Which one is it going to be?\n\nNone of the above.  After going back and forth this long, I won't\nwant to pick an incremental from the middle of discussion, so (1) is\nout.  This is not my itch and I am only helping you in a way that\nthe result will not hurt the project, so (2) is not it.  But\nassuming that \"checkout that is done as an implementation detail in\nrebase is _not_ checkout from end user's point of view\" is where we\nwant to go, discarding this series is not something we want to see,\neither.\n\nA rerolled series that does:\n\n - Tweak wt-status.c to take information not from reflog, when\n   detached during rebase (this may need to tweak existing tests,\n   as different \"rebase\" modes may use 'checkout' liberally in\n   different ways);\n\n - Teach builtin/commit.c to pay attention to reflog-action; thanks\n   to the previous step, this will not have to change the tests;\n\n - Update the reflog message rebase uses, but again this will not\n   affect wt-status.c at all.\n\nwould be one way to go.\n"},{"id":"220982","messageId":"CALkWK0kzGTHMv2x8mrgftVGX1OwtvVdb9_8jrXnV=fQCfPw9XQ@mail.gmail.com","threadId":"34124","inReplyTo":"7vip1ek37o.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] status: do not depend on flaky reflog messages","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-16T06:07:43Z","receivedAt":"2013-06-16T06:07:43Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> [...]\n\nI have no desire to argue incessantly.  I just want a solution to the problem!\n\n> A rerolled series that does:\n>\n>  - Tweak wt-status.c to take information not from reflog, when\n>    detached during rebase (this may need to tweak existing tests,\n>    as different \"rebase\" modes may use 'checkout' liberally in\n>    different ways);\n\nPlease be more specific, and tell me what it should print when a\nrebase is in progress.  Would a constant\n\n  # rebase in progress; onto $ONTO\n\nbe sufficient?\n\n>  - Teach builtin/commit.c to pay attention to reflog-action; thanks\n>    to the previous step, this will not have to change the tests;\n\nWhere did builtin/commit.c enter into the equation?  Doesn't it\nalready respect GIT_REFLOG_ACTION?  See line 1461.\n\n>  - Update the reflog message rebase uses, but again this will not\n>    affect wt-status.c at all.\n\nOkay.\n"}]}