[BUG] git symbolic-ref does not recognize @ as the shortcut for HEAD

[BUG] git symbolic-ref does not recognize @ as the shortcut for HEAD

[Mathieu Lemoine]

Hello,

In https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt
is mentioned:

 * Instead of typing four capital letters "HEAD", you can say "@" now,
e.g. "git log @".

However, `git symbolic-ref @`  gives "fatal: No such ref: @", while
`git symbolic-ref @`  gives "refs/heads/master".

I looked around in the archive and #git, but nobody seemed to be aware
of the behaviour.

I wonder if it's on purpose given the low level of symbolic-ref or if
it's a bug.

Mathieu Lemoine.

[BUG] "git rebase": fatal: Not a valid object name: ''

[Andreas Krey]

Hi, everyone,

since ad8261d (rebase: use reflog to find common base with upstream)
a rebase without arguments says "fatal: Not a valid object name: ''",
caused by trying to determine the fork point with an empty $switch_to.

I don't really see what the appropriate fix would be. :-(

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: [BUG] "git rebase": fatal: Not a valid object name: ''

[John Keeping]

On Thu, Jan 09, 2014 at 04:36:18PM +0100, Andreas Krey wrote:
> since ad8261d (rebase: use reflog to find common base with upstream)
> a rebase without arguments says "fatal: Not a valid object name: ''",
> caused by trying to determine the fork point with an empty $switch_to.
> 
> I don't really see what the appropriate fix would be. :-(

I think the correct fix is to change the "$switch_to" in the call to
"git merge-base --fork-point" to "${switch_to:-HEAD}", but I'm not at a
machine where I can test that or work up a patch at the moment...

Re: [BUG] "git rebase": fatal: Not a valid object name: ''

[Andreas Krey]

On Thu, 09 Jan 2014 15:56:21 +0000, John Keeping wrote:
...
> I think the correct fix is to change the "$switch_to" in the call to
> "git merge-base --fork-point" to "${switch_to:-HEAD}", but I'm not at a
> machine where I can test that or work up a patch at the moment...

Thanks, looks plausible and works. Need to catch train myself now.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

[PATCH] rebase: fix fork-point with zero arguments

[John Keeping]

When no arguments are specified, $switch_to is empty so we end up
passing the empty string to "git merge-base --fork-point", which causes
an error.  git-rebase carries on at this point, but in fact we have
failed to apply the fork-point operation.

It turns out that the test in t3400 that was meant to test this didn't
actually need the fork-point behaviour, so enhance it to make sure that
the fork-point is applied correctly.  The modified test fails without
the change to git-rebase.sh in this patch.

Reported-by: Andreas Krey <a.krey@gmx.de>
Signed-off-by: John Keeping <john@keeping.me.uk>
---
 git-rebase.sh     |  3 ++-
 t/t3400-rebase.sh | 12 ++++++++++--
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 7185dc8..8a3efa2 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -534,7 +534,8 @@ esac
 
 if test "$fork_point" = t
 then
-	new_upstream=$(git merge-base --fork-point "$upstream_name" "$switch_to")
+	new_upstream=$(git merge-base --fork-point "$upstream_name" \
+			"${switch_to:-HEAD}")
 	if test -n "$new_upstream"
 	then
 		upstream=$new_upstream
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index 998503d..6d94b1f 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -135,11 +135,19 @@ test_expect_success 'fail when upstream arg is missing and not configured' '
 '
 
 test_expect_success 'default to common base in @{upstream}s reflog if no upstream arg' '
+	git checkout -b default-base master &&
 	git checkout -b default topic &&
 	git config branch.default.remote . &&
-	git config branch.default.merge refs/heads/master &&
+	git config branch.default.merge refs/heads/default-base &&
 	git rebase &&
-	git rev-parse --verify master >expect &&
+	git rev-parse --verify default-base >expect &&
+	git rev-parse default~1 >actual &&
+	test_cmp expect actual &&
+	git checkout default-base &&
+	git reset --hard HEAD^ &&
+	git checkout default &&
+	git rebase &&
+	git rev-parse --verify default-base >expect &&
 	git rev-parse default~1 >actual &&
 	test_cmp expect actual
 '
-- 
1.8.5.226.g0d60d77

Re: [BUG] git symbolic-ref does not recognize @ as the shortcut for HEAD

[Duy Nguyen]

On Thu, Jan 9, 2014 at 10:05 PM, Mathieu Lemoine <mathieu@mlemoine.name> wrote:
> Hello,
>
> In https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt
> is mentioned:
>
>  * Instead of typing four capital letters "HEAD", you can say "@" now,
> e.g. "git log @".
>
> However, `git symbolic-ref @`  gives "fatal: No such ref: @", while
> `git symbolic-ref @`  gives "refs/heads/master".

you meant "while `git symbolic-ref _HEAD_` gives refs/heads/master"?

> I looked around in the archive and #git, but nobody seemed to be aware
> of the behaviour.
>
> I wonder if it's on purpose given the low level of symbolic-ref or if
> it's a bug.

I think this is because symbolic-ref (and show-ref) takes plain refs,
either in full or short form, but nothing else fancier. I'm not sure
if we should add support for @ (and maybe @{u} as it's in the same
boat) to these commands. If it's confusing and hard to explain in
documents then maybe we should.
-- 
Duy