Re: [RFC/PATCH] branch: name detached HEAD analogous to status
On 15-02-22 02:21 PM, Junio C Hamano wrote: Michael J Gruber g...@drmicha.warpmail.net writes: 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. Yeah, otherwise the user would wonder why sometimes the object name after that from matches git rev-parse HEAD and sometimes does not. In order to make sure that it will be easy for us to maintain that these two commands will keep using the same logic and wording after this fix is applied, should this patch do a bit more? Or is it worth doing that for such a small piece of code to be shared? The following is a tangent and I do not think it is likely we would do anything about it, but I wonder what value we give the end users by showing the from information, both in status and branch in the first place. When I am on a detached HEAD, I'd be doing one of these three things: (1) I am on some kind of sequencing machinery (e.g. rebase -i, cherry-pick A..B, or bisect). It does not matter to me at all if I am at the same commit at which I started the sequenced operations or the sequencing machinery has moved me one or more commits along its planned course of action, or where the original point the sequencing machinery detached the HEAD at. I suspect that I would not use git status or git branch in this mode anyway. (2) I am sight-seeing, starting with e.g. git checkout v2.0.0, and moving around with git checkout $some_other_commit. I'd always see that I am at the commit I last checked out, so the distinctions would not be even shown to me. (3) I am experimenting to fix or enhance an existing thing that is meant to eventually hit a concrete branch, but I do not know if the experiment would pan out. git checkout $topic~$n would be to start from near the tip of that $topic ($n may often be 0 but not always) and then I would git commit my experiments. When I assess my progress, I'd be interested in what I have that is not in $topic and vice versa since I started that experiment, so I find it very useful, because I often work on HEADs detached from remote branches (git checkout origin/foo). If I'm sight-seeing, I like the reminder of which remote branch I checked out, especially because I often have several working tress going at the same time. I also often make trivial changes, like typo fixes, on such detached HEADs, and here too I appreciate the reminder of which remote branch I should push HEAD to. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] branch: name detached HEAD analogous to status
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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] branch: name detached HEAD analogous to status
Marc Branchaud venit, vidit, dixit 23.02.2015 16:12: 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. 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] branch: name detached HEAD analogous to status
On 15-02-23 11:24 AM, Michael J Gruber wrote: Marc Branchaud venit, vidit, dixit 23.02.2015 16:12: 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. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] branch: name detached HEAD analogous to status
Junio C Hamano venit, vidit, dixit 22.02.2015 20:21: Michael J Gruber g...@drmicha.warpmail.net writes: 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. Yeah, otherwise the user would wonder why sometimes the object name after that from matches git rev-parse HEAD and sometimes does not. In order to make sure that it will be easy for us to maintain that these two commands will keep using the same logic and wording after this fix is applied, should this patch do a bit more? Or is it worth doing that for such a small piece of code to be shared? Yes, I guess I meant RFD when I meant RFC. If that consistency is deemed worthwhile it should at least be guaranteed by the tests, which the test amendments somehow do, but better by a shared code in wt-status.c. That could possibly be reused by the decorate code - which is how I came about this: In order to decide about consistent HEAD decorations I checked what we have and got confused by status vs. branch. The following is a tangent and I do not think it is likely we would do anything about it, but I wonder what value we give the end users by showing the from information, both in status and branch in the first place. When I am on a detached HEAD, I'd be doing one of these three things: (1) I am on some kind of sequencing machinery (e.g. rebase -i, cherry-pick A..B, or bisect). It does not matter to me at all if I am at the same commit at which I started the sequenced operations or the sequencing machinery has moved me one or more commits along its planned course of action, or where the original point the sequencing machinery detached the HEAD at. I suspect that I would not use git status or git branch in this mode anyway. (2) I am sight-seeing, starting with e.g. git checkout v2.0.0, and moving around with git checkout $some_other_commit. I'd always see that I am at the commit I last checked out, so the distinctions would not be even shown to me. (3) I am experimenting to fix or enhance an existing thing that is meant to eventually hit a concrete branch, but I do not know if the experiment would pan out. git checkout $topic~$n would be to start from near the tip of that $topic ($n may often be 0 but not always) and then I would git commit my experiments. When I assess my progress, I'd be interested in what I have that is not in $topic and vice versa since I started that experiment, so $ git log ...$topic $ git show-branch HEAD $topic would be a lot more useful than having to learn where did I detach from either status or branch and then do something about that the abbreviated object name (like feeding it to describe or log). Of course, the decision to make the point the HEAD was originally detached at is not an issue this patch introduces, but it makes me wonder if that existing at vs from logic is an overall win or a loss. Not for you nor anyone who routinely detaches heads :) Despite HEAD reflog and delayed pruning and all that, detached HEAD is a state the average user may feel slightly uncomfortable with, and may not even have gotten into on purpose. git checkout tag and git checkout remotebranch are very easy ways to get there, even git checkout HEAD^1 and such when mistaking checkout for reset. Therefore, I think about that at/from as information (or rather: quick guesstimate) on two things: - How did I get there? (For this it might be better to say 'at/from HEAD^1' which was sha1 rather than resolving that to a sha1 only. I dunno. Detached heads move so easily...) - Has something (that could get lost) happened since? We take a quick and overly cautious approach to answering the 2nd question, of course. Maybe a git head command would be really a better place for all that information: git head master or HEAD (on branch resp. detached state) git head -v master at... or HEAD at ..., detached from/at... git head -l list of sha1s of childless prunable commits from HEAD's reflog git head -d|--detach alias for git checkout -detach HEAD (just brainstorming) Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] branch: name detached HEAD analogous to status
Michael J Gruber g...@drmicha.warpmail.net writes: 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. Yeah, otherwise the user would wonder why sometimes the object name after that from matches git rev-parse HEAD and sometimes does not. In order to make sure that it will be easy for us to maintain that these two commands will keep using the same logic and wording after this fix is applied, should this patch do a bit more? Or is it worth doing that for such a small piece of code to be shared? The following is a tangent and I do not think it is likely we would do anything about it, but I wonder what value we give the end users by showing the from information, both in status and branch in the first place. When I am on a detached HEAD, I'd be doing one of these three things: (1) I am on some kind of sequencing machinery (e.g. rebase -i, cherry-pick A..B, or bisect). It does not matter to me at all if I am at the same commit at which I started the sequenced operations or the sequencing machinery has moved me one or more commits along its planned course of action, or where the original point the sequencing machinery detached the HEAD at. I suspect that I would not use git status or git branch in this mode anyway. (2) I am sight-seeing, starting with e.g. git checkout v2.0.0, and moving around with git checkout $some_other_commit. I'd always see that I am at the commit I last checked out, so the distinctions would not be even shown to me. (3) I am experimenting to fix or enhance an existing thing that is meant to eventually hit a concrete branch, but I do not know if the experiment would pan out. git checkout $topic~$n would be to start from near the tip of that $topic ($n may often be 0 but not always) and then I would git commit my experiments. When I assess my progress, I'd be interested in what I have that is not in $topic and vice versa since I started that experiment, so $ git log ...$topic $ git show-branch HEAD $topic would be a lot more useful than having to learn where did I detach from either status or branch and then do something about that the abbreviated object name (like feeding it to describe or log). Of course, the decision to make the point the HEAD was originally detached at is not an issue this patch introduces, but it makes me wonder if that existing at vs from logic is an overall win or a loss. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 g...@drmicha.warpmail.net
---
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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
