[RFC/PATCH] branch: name detached HEAD analogous to status

"git status" carefully names a detached HEAD "at" resp. "from" a rev or
ref depending on whether the detached HEAD has moved since. "git branch"
always uses "from", which can be confusing, because a status-aware user
would interpret this as moved detached HEAD.

Make "git branch" use the same logic and wording.

Signed-off-by: Michael J Gruber <redacted>
---

Notes:
    The wording is still different:
    
    HEAD detached at %s
    * (detached at %s)
    
    for status (line 1) resp. branch (line 2). Maybe it's worthwhile to use the
    exact same string so that l10n output is guaranteed to be the same? E.g.
    
    a)
    HEAD detached at %s
    * (HEAD detached at %s)
    
    or
    b)
    HEAD (detached at %s)
    * (detached at %s)
    
    In case b), "git status" strings would need to change, in case a)
    only "git branch" strings which change anyway by this patch.

 builtin/branch.c         | 13 ++++++++++---
 t/t3203-branch-output.sh | 39 ++++++++++++++++++++++++++++++++++++++-
 2 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/builtin/branch.c b/builtin/branch.c
index d8949cb..be391ee 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c

@@ -589,9 +589,16 @@ static char *get_head_description(void)
 	else if (state.bisect_in_progress)
 		strbuf_addf(&desc, _("(no branch, bisect started on %s)"),
 			    state.branch);
-	else if (state.detached_from)
-		strbuf_addf(&desc, _("(detached from %s)"),
-			    state.detached_from);
+	else if (state.detached_from) {
+		unsigned char sha1[20];
+		if (!get_sha1("HEAD", sha1) &&
+		    !hashcmp(sha1, state.detached_sha1))
+			strbuf_addf(&desc, _("(detached at %s)"),
+				state.detached_from);
+		else
+			strbuf_addf(&desc, _("(detached from %s)"),
+				state.detached_from);
+	}
 	else
 		strbuf_addstr(&desc, _("(no branch)"));
 	free(state.branch);

diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index ba4f98e..aaff885 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh

@@ -96,7 +96,7 @@ test_expect_success 'git branch -v pattern does not show branch summaries' '
 
 test_expect_success 'git branch shows detached HEAD properly' '
 	cat >expect <<EOF &&
-* (detached from $(git rev-parse --short HEAD^0))
+* (detached at $(git rev-parse --short HEAD^0))
   branch-one
   branch-two
   master

@@ -106,4 +106,41 @@ EOF
 	test_i18ncmp expect actual
 '
 
+test_expect_success 'git branch shows detached HEAD properly after moving' '
+	cat >expect <<EOF &&
+* (detached from $(git rev-parse --short HEAD))
+  branch-one
+  branch-two
+  master
+EOF
+	git reset --hard HEAD^1 &&
+	git branch >actual &&
+	test_i18ncmp expect actual
+'
+
+test_expect_success 'git branch shows detached HEAD properly from tag' '
+	cat >expect <<EOF &&
+* (detached at fromtag)
+  branch-one
+  branch-two
+  master
+EOF
+	git tag fromtag master &&
+	git checkout fromtag &&
+	git branch >actual &&
+	test_i18ncmp expect actual
+'
+
+test_expect_success 'git branch shows detached HEAD properly after moving from tag' '
+	cat >expect <<EOF &&
+* (detached from fromtag)
+  branch-one
+  branch-two
+  master
+EOF
+	git reset --hard HEAD^1 &&
+	git branch >actual &&
+	test_i18ncmp expect actual
+'
+
 test_done

-- 
2.3.0.296.g32c87e1

On 15-02-22 12:38 PM, Michael J Gruber wrote:

"git status" carefully names a detached HEAD "at" resp. "from" a rev or
ref depending on whether the detached HEAD has moved since. "git branch"
always uses "from", which can be confusing, because a status-aware user
would interpret this as moved detached HEAD.

Make "git branch" use the same logic and wording.

Except that the wording in "git branch" is more correct, especially if the
detached HEAD contains new commits.

In other words, "at" is only correct if the detached HEAD matches the ref.
If the HEAD has other commits, it is no longer "at" that ref but instead it
has grown "from" it.

But even if the detached HEAD matches the ref, saying it came "from" that ref
(with 0 extra commits) is still better than saying
detached-HEAD-with-extra-commits is "at" the ref.

		M.

Marc Branchaud venit, vidit, dixit 23.02.2015 16:12:

On 15-02-22 12:38 PM, Michael J Gruber wrote:

quoted

"git status" carefully names a detached HEAD "at" resp. "from" a rev or
ref depending on whether the detached HEAD has moved since. "git branch"
always uses "from", which can be confusing, because a status-aware user
would interpret this as moved detached HEAD.

Make "git branch" use the same logic and wording.

Except that the wording in "git branch" is more correct, especially if the
detached HEAD contains new commits.

In other words, "at" is only correct if the detached HEAD matches the ref.
If the HEAD has other commits, it is no longer "at" that ref but instead it
has grown "from" it.

Sure, but that's exactly what git status does. Haven't you tried out?

And it's exactly what I suggest for git branch. It conveys more information.

But even if the detached HEAD matches the ref, saying it came "from" that ref
(with 0 extra commits) is still better than saying
detached-HEAD-with-extra-commits is "at" the ref.

Why? Both are true. "at" conveys the additional information that HEAD is
still at the that rev.

Michael

On 15-02-23 11:24 AM, Michael J Gruber wrote:

Marc Branchaud venit, vidit, dixit 23.02.2015 16:12:

quoted

On 15-02-22 12:38 PM, Michael J Gruber wrote:

quoted

"git status" carefully names a detached HEAD "at" resp. "from" a rev or
ref depending on whether the detached HEAD has moved since. "git branch"
always uses "from", which can be confusing, because a status-aware user
would interpret this as moved detached HEAD.

Make "git branch" use the same logic and wording.

Except that the wording in "git branch" is more correct, especially if the
detached HEAD contains new commits.

In other words, "at" is only correct if the detached HEAD matches the ref.
If the HEAD has other commits, it is no longer "at" that ref but instead it
has grown "from" it.

Sure, but that's exactly what git status does. Haven't you tried out?

And it's exactly what I suggest for git branch. It conveys more information.

Oops, right.  Sorry, I got blinded by the various "detached at" examples in
your patch's notes.

		M.