threads / patch / 33673

patchAdd new @ shortcut for HEAD

Subject: [PATCH] Add new @ shortcut for HEAD

## tl;dr

56 messages between Apr 29, 2013 and Apr 30, 2013. Diffs are folded; open one to read it.

replies: 55people: 7as markdown or json

Felipe Contreras· Apr 29, 2013, 19:35 UTC · lore

So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?

This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with 'master@'.

So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can use 'git show @~1', and all that goody goodness.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---

People have complained about the lack of a HEAD shortcut before, and some proposals have been made, but I think this one is a clean trick in accordance with our current syntax.

 Documentation/revisions.txt | 3 +++
 sha1_name.c                 | 8 +++++++-
 t/t1503-rev-parse-verify.sh | 9 +++++++++
 3 files changed, 19 insertions(+), 1 deletion(-)
Show changes to 3 files +19 −1

Documentation/revisions.txt, sha1_name.c, t/t1503-rev-parse-verify.sh

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index d477b3f..6315ce5 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -58,6 +58,9 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.
 While the ref name encoding is unspecified, UTF-8 is preferred as
 some output processing may assume ref names in UTF-8.
 
+'@'::
+  '@' alone is a shortcut for 'HEAD'
+
 '<refname>@\{<date>\}', e.g. 'master@\{yesterday\}', 'HEAD@\{5 minutes ago\}'::
   A ref followed by the suffix '@' with a date specification
   enclosed in a brace
diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..d7c3d6f 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -437,11 +437,15 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 	static const char *warn_msg = "refname '%.*s' is ambiguous.";
 	char *real_ref = NULL;
 	int refs_found = 0;
-	int at, reflog_len;
+	int at, reflog_len, empty_at;
 
 	if (len == 40 && !get_sha1_hex(str, sha1))
 		return 0;
 
+	empty_at = len && str[len-1] == '@';
+	if (empty_at)
+		len = len-1;
+
 	/* basic@{time or number or -number} format to query ref-log */
 	reflog_len = at = 0;
 	if (len && str[len-1] == '}') {
@@ -475,6 +479,8 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 		refs_found = dwim_ref("HEAD", 4, sha1, &real_ref);
 	} else if (reflog_len)
 		refs_found = dwim_log(str, len, sha1, &real_ref);
+	else if (!len && empty_at)
+		refs_found = dwim_ref("HEAD", 4, sha1, &real_ref);
 	else
 		refs_found = dwim_ref(str, len, sha1, &real_ref);
 
diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh
index 813cc1b..426c63f 100755
--- a/t/t1503-rev-parse-verify.sh
+++ b/t/t1503-rev-parse-verify.sh
@@ -115,4 +115,13 @@ test_expect_success 'master@{n} for various n' '
 	test_must_fail git rev-parse --verify master@{$Np1}
 '
 
+test_expect_success 'empty @' '
+	rev_hash=$(git rev-parse --verify @) &&
+	test "$rev_hash" = "$HASH4" &&
+	rev_hash=$(git rev-parse --verify HEAD@) &&
+	test "$rev_hash" = "$HASH4" &&
+	rev_hash=$(git rev-parse --verify master@) &&
+	test "$rev_hash" = "$HASH4"
+'
+
 test_done
-- 
1.8.2.1.1031.g2ee5873
Ramkumar Ramachandra· Apr 29, 2013, 19:43 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras wrote:
> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
> use 'git show @~1', and all that goody goodness.
Good one.  This is what I didn't think of.

The implementation looks beautiful, and I have nothing more to say about the patch.

Junio C Hamano· Apr 29, 2013, 20:01 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 15 quoted lines
> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>
> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
> 'master@'.
>
> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
> use 'git show @~1', and all that goody goodness.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>
> People have complained about the lack of a HEAD shortcut before, and some
> proposals have been made, but I think this one is a clean trick in accordance
> with our current syntax.

Technically the notation would be only valid if you have a reflog on it, but if we must have such a notation, I think this may end up to be the least bad one. I haven't thought things through, though, so won't stand behind it myself (i.e. when there are corner-case holes found later, I won't defend the notation myself), at least not yet.

Felipe Contreras· Apr 29, 2013, 20:14 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Mon, Apr 29, 2013 at 3:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 23 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>>
>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>> 'master@'.
>>
>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>> use 'git show @~1', and all that goody goodness.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>>
>> People have complained about the lack of a HEAD shortcut before, and some
>> proposals have been made, but I think this one is a clean trick in accordance
>> with our current syntax.
>
> Technically the notation would be only valid if you have a reflog on
> it, but if we must have such a notation, I think this may end up to
> be the least bad one.  I haven't thought things through, though, so
> won't stand behind it myself (i.e. when there are corner-case holes
> found later, I won't defend the notation myself), at least not yet.
But @ is not used just for reflogs, there's @{now}, @{-1}, @{upstream}.
-- 
Felipe Contreras
Junio C Hamano· Apr 29, 2013, 20:24 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras <felipe.contreras@gmail.com> writes:
> But @ is not used just for reflogs, there's @{now}, @{-1}, @{upstream}.

True. @{now} is a reflog, @{-1} is also but @{u} is not. It is a kitchen sink and you shouldn't have to have reflog on a branch in order to use @{upstream} (I didn't check---I wouldn't be surprised if the code for @{u} is buggy and barfed).

Felipe Contreras· Apr 29, 2013, 20:38 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Mon, Apr 29, 2013 at 3:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> But @ is not used just for reflogs, there's @{now}, @{-1}, @{upstream}.
>
> True.  @{now} is a reflog, @{-1} is also but @{u} is not.  It is a
> kitchen sink and you shouldn't have to have reflog on a branch in
> order to use @{upstream} (I didn't check---I wouldn't be surprised
> if the code for @{u} is buggy and barfed).

It shouldn't matter if @{u} is buggy or not (which I doubt), @ is basically @{nothing}, or @{same-commit}, whether a reflog is present or not doesn't really matter. HEAD@ -> HEAD, master@ -> master, and so on.

-- 
Felipe Contreras
Junio C Hamano· Apr 29, 2013, 21:01 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras <felipe.contreras@gmail.com> writes:
> It shouldn't matter if @{u} is buggy or not (which I doubt),

Oh, it wouldn't make any difference to this topic; it is just something we may want to fix if it were broken.

Junio C Hamano· Apr 29, 2013, 20:02 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras <felipe.contreras@gmail.com> writes:
> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
Another technical issue, even if you have reflogs.

HEAD@{0} and @{0} are referring to two different reflogs, and means different things, even though they may refer to the same commit.

But the comment in my previous message still stands.
Felipe Contreras· Apr 29, 2013, 20:23 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Mon, Apr 29, 2013 at 3:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>
> Another technical issue, even if you have reflogs.
>
> HEAD@{0} and @{0} are referring to two different reflogs, and means
> different things, even though they may refer to the same commit.
How? AFAICS the code substitutes @{0} with HEAD@{0}.

Plus 'git show HEAD@{1}', 'git show current-branch@{1}', and 'git show @{1}' all show the same thing, even though 'git relog HEAD' shows a different commit for HEAD@{1}.

-- 
Felipe Contreras
Felipe Contreras· Apr 29, 2013, 21:36 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Mon, Apr 29, 2013 at 3:23 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 16 quoted lines
> On Mon, Apr 29, 2013 at 3:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>>> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>>
>> Another technical issue, even if you have reflogs.
>>
>> HEAD@{0} and @{0} are referring to two different reflogs, and means
>> different things, even though they may refer to the same commit.
>
> How? AFAICS the code substitutes @{0} with HEAD@{0}.
>
> Plus 'git show HEAD@{1}', 'git show current-branch@{1}', and 'git show
> @{1}' all show the same thing, even though 'git relog HEAD' shows a
> different commit for HEAD@{1}.

Never-mind, now I see the difference, still, I don't think it's relevant for this patch.

-- 
Felipe Contreras
Junio C Hamano· Apr 29, 2013, 22:50 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras <felipe.contreras@gmail.com> writes:
> Never-mind, now I see the difference, still, I don't think it's
> relevant for this patch.

I don't either. With the precedence of @{u}, @ does not need to have anything to do with a reflog. It is just a random letter that casts a magic spell.

Jonathan Nieder· Apr 30, 2013, 00:53 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 6 quoted lines
>> Never-mind, now I see the difference, still, I don't think it's
>> relevant for this patch.
>
> I don't either. With the precedence of @{u}, @ does not need to have
> anything to do with a reflog. It is just a random letter that casts
> a magic spell.

I thought the convention was "^{...} is for operators that act on objects, @{...} for operators that act on refs or symrefs".

Which works fine here.
Junio C Hamano· Apr 30, 2013, 17:54 UTC · re: Jonathan Nieder · lore

Re: [PATCH] Add new @ shortcut for HEAD

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 12 quoted lines
> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> Never-mind, now I see the difference, still, I don't think it's
>>> relevant for this patch.
>>
>> I don't either. With the precedence of @{u}, @ does not need to have
>> anything to do with a reflog. It is just a random letter that casts
>> a magic spell.
>
> I thought the convention was "^{...} is for operators that act on
> objects, @{...} for operators that act on refs or symrefs".

Almost. You can ask "git rev-parse --symbolic-full-name" to see that @{-1} is still a ref, but @{1} is _not_ a ref (it is a concrete revision that you cannot run 'update-ref' on).

Felipe Contreras· Apr 30, 2013, 18:17 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 12:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 18 quoted lines
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Junio C Hamano wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>>> Never-mind, now I see the difference, still, I don't think it's
>>>> relevant for this patch.
>>>
>>> I don't either. With the precedence of @{u}, @ does not need to have
>>> anything to do with a reflog. It is just a random letter that casts
>>> a magic spell.
>>
>> I thought the convention was "^{...} is for operators that act on
>> objects, @{...} for operators that act on refs or symrefs".
>
> Almost.  You can ask "git rev-parse --symbolic-full-name" to see
> that @{-1} is still a ref, but @{1} is _not_ a ref (it is a concrete
> revision that you cannot run 'update-ref' on).
This has nothing to do with this documentation.
Show changes to 2 files +3 −1

Documentation/git-check-ref-format.txt, refs.c

diff --git a/Documentation/git-check-ref-format.txt
b/Documentation/git-check-ref-format.txt
index ec1739a..4764975 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -52,7 +52,7 @@ Git imposes the following rules on how references are named:

 . They cannot end with a dot `.`.

-. They cannot contain a sequence `@{`.
+. They cannot contain a sequence `@{` or end with `@`.

 . They cannot contain a `\`.

diff --git a/refs.c b/refs.c
index de2d8eb..99ac4f6 100644
--- a/refs.c
+++ b/refs.c
@@ -95,6 +95,8 @@ int check_refname_format(const char *refname, int flags)

        if (refname[component_len - 1] == '.')
                return -1; /* Refname ends with '.'. */
+       if (refname[component_len - 1] == '@')
+               return -1; /* Refname ends with '@'. */
        if (!(flags & REFNAME_ALLOW_ONELEVEL) && component_count < 2)
                return -1; /* Refname has only one component. */
        return 0;

% git update-ref master@ master
fatal: Cannot lock the ref 'master@'.
-- 
Felipe Contreras
Junio C Hamano· Apr 29, 2013, 22:38 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 16 quoted lines
> diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh
> index 813cc1b..426c63f 100755
> --- a/t/t1503-rev-parse-verify.sh
> +++ b/t/t1503-rev-parse-verify.sh
> @@ -115,4 +115,13 @@ test_expect_success 'master@{n} for various n' '
>  	test_must_fail git rev-parse --verify master@{$Np1}
>  '
>  
> +test_expect_success 'empty @' '
> +	rev_hash=$(git rev-parse --verify @) &&
> +	test "$rev_hash" = "$HASH4" &&
> +	rev_hash=$(git rev-parse --verify HEAD@) &&
> +	test "$rev_hash" = "$HASH4" &&
> +	rev_hash=$(git rev-parse --verify master@) &&
> +	test "$rev_hash" = "$HASH4"
> +'

Don't we have different refs that resolve to something other than $HASH4 at this point in the test? Otherwise we wouldn't notice a breakage because we cannot tell if HEAD@ and master@ are interpreted correctly or all of these happen to yield $HASH4 because a version somebody else patches to break the implementation in this patch discards any string before @ that is not followed by {stuff}.

Felipe Contreras· Apr 29, 2013, 22:49 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Mon, Apr 29, 2013 at 5:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 21 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh
>> index 813cc1b..426c63f 100755
>> --- a/t/t1503-rev-parse-verify.sh
>> +++ b/t/t1503-rev-parse-verify.sh
>> @@ -115,4 +115,13 @@ test_expect_success 'master@{n} for various n' '
>>       test_must_fail git rev-parse --verify master@{$Np1}
>>  '
>>
>> +test_expect_success 'empty @' '
>> +     rev_hash=$(git rev-parse --verify @) &&
>> +     test "$rev_hash" = "$HASH4" &&
>> +     rev_hash=$(git rev-parse --verify HEAD@) &&
>> +     test "$rev_hash" = "$HASH4" &&
>> +     rev_hash=$(git rev-parse --verify master@) &&
>> +     test "$rev_hash" = "$HASH4"
>> +'
>
> Don't we have different refs that resolve to something other than
> $HASH4 at this point in the test?
No.
Show 5 quoted lines
> Otherwise we wouldn't notice a
> breakage because we cannot tell if HEAD@ and master@ are interpreted
> correctly or all of these happen to yield $HASH4 because a version
> somebody else patches to break the implementation in this patch
> discards any string before @ that is not followed by {stuff}.
        rev_hash=$(git rev-parse --verify HEAD@) &&
        test "$rev_hash" = "$HASH4" &&
        rev_hash=$(git rev-parse --verify master@) &&
-       test "$rev_hash" = "$HASH4"
+       test "$rev_hash" = "$HASH4" &&
+       test_must_fail git rev-parse --verify foo@
-- 
Felipe Contreras
Junio C Hamano· Apr 29, 2013, 23:06 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

The following message is a courtesy copy of an article that has been posted to gmane.comp.version-control.git as well.

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 24 quoted lines
> On Mon, Apr 29, 2013 at 5:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh
>>> index 813cc1b..426c63f 100755
>>> --- a/t/t1503-rev-parse-verify.sh
>>> +++ b/t/t1503-rev-parse-verify.sh
>>> @@ -115,4 +115,13 @@ test_expect_success 'master@{n} for various n' '
>>>       test_must_fail git rev-parse --verify master@{$Np1}
>>>  '
>>>
>>> +test_expect_success 'empty @' '
>>> +     rev_hash=$(git rev-parse --verify @) &&
>>> +     test "$rev_hash" = "$HASH4" &&
>>> +     rev_hash=$(git rev-parse --verify HEAD@) &&
>>> +     test "$rev_hash" = "$HASH4" &&
>>> +     rev_hash=$(git rev-parse --verify master@) &&
>>> +     test "$rev_hash" = "$HASH4"
>>> +'
>>
>> Don't we have different refs that resolve to something other than
>> $HASH4 at this point in the test?
>
> No.
Of course we're free to make some as needed; perhaps like this?
 t/t1503-rev-parse-verify.sh | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
Show changes to t/t1503-rev-parse-verify.sh +7 −2
diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh
index 426c63f..f8f3b34 100755
--- a/t/t1503-rev-parse-verify.sh
+++ b/t/t1503-rev-parse-verify.sh
@@ -115,13 +115,18 @@ test_expect_success 'master@{n} for various n' '
 	test_must_fail git rev-parse --verify master@{$Np1}
 '
 
-test_expect_success 'empty @' '
+test_expect_success 'empty @ and ref@ without trailing {stuff}' '
+	test_when_finished "git branch -d twoago" &&
+	git branch twoago HEAD~2 &&
 	rev_hash=$(git rev-parse --verify @) &&
 	test "$rev_hash" = "$HASH4" &&
 	rev_hash=$(git rev-parse --verify HEAD@) &&
 	test "$rev_hash" = "$HASH4" &&
 	rev_hash=$(git rev-parse --verify master@) &&
-	test "$rev_hash" = "$HASH4"
+	test "$rev_hash" = "$HASH4" &&
+	rev_hash=$(git rev-parse --verify twoago@) &&
+	test "$rev_hash" = "$HASH2" &&
+	test_must_fail git rev-parse --verify nosuch@
 '
 
 test_done
Felipe Contreras· Apr 29, 2013, 23:10 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Mon, Apr 29, 2013 at 6:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 21 quoted lines
> --- a/t/t1503-rev-parse-verify.sh
> +++ b/t/t1503-rev-parse-verify.sh
> @@ -115,13 +115,18 @@ test_expect_success 'master@{n} for various n' '
>         test_must_fail git rev-parse --verify master@{$Np1}
>  '
>
> -test_expect_success 'empty @' '
> +test_expect_success 'empty @ and ref@ without trailing {stuff}' '
> +       test_when_finished "git branch -d twoago" &&
> +       git branch twoago HEAD~2 &&
>         rev_hash=$(git rev-parse --verify @) &&
>         test "$rev_hash" = "$HASH4" &&
>         rev_hash=$(git rev-parse --verify HEAD@) &&
>         test "$rev_hash" = "$HASH4" &&
>         rev_hash=$(git rev-parse --verify master@) &&
> -       test "$rev_hash" = "$HASH4"
> +       test "$rev_hash" = "$HASH4" &&
> +       rev_hash=$(git rev-parse --verify twoago@) &&
> +       test "$rev_hash" = "$HASH2" &&
> +       test_must_fail git rev-parse --verify nosuch@
>  '
Sure, but none of the tests above do that. Up to you.
-- 
Felipe Contreras
Duy Nguyen· Apr 30, 2013, 05:54 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
> use 'git show @~1', and all that goody goodness.

I like this. I haven't spent a lot of time on thinking about ambiguation. But I think we're safe there. '@' is not overloaded much like ':', '^' or '~'.

> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
> 'master@'.

I'm a bit reluctant to this. It looks like incomplete syntax to me as '@' has always been followed by '{'. Can we have the lone '@' candy but reject master@ and HEAD@? There's no actual gain in writing master@ vs master@{0}.

> +'@'::
> +  '@' alone is a shortcut for 'HEAD'
> +

And this does not explain about HEAD@ or master@. But because I prefer the candy part only. This documentation part looks good :) -- Duy

Felipe Contreras· Apr 30, 2013, 06:10 UTC · re: Duy Nguyen · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 16 quoted lines
> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>> use 'git show @~1', and all that goody goodness.
>
> I like this. I haven't spent a lot of time on thinking about
> ambiguation. But I think we're safe there. '@' is not overloaded much
> like ':', '^' or '~'.
>
>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>> 'master@'.
>
> I'm a bit reluctant to this. It looks like incomplete syntax to me as
> '@' has always been followed by '{'. Can we have the lone '@' candy
> but reject master@ and HEAD@? There's no actual gain in writing
> master@ vs master@{0}.

That's what I tried first, but it just didn't feel elegant to have one check for this case only. foo@ does follow naturally, and it doesn't hurt.

Show 6 quoted lines
>> +'@'::
>> +  '@' alone is a shortcut for 'HEAD'
>> +
>
> And this does not explain about HEAD@ or master@. But because I prefer
> the candy part only. This documentation part looks good :)

Yeah, there's no point in documenting things that are not useful for the user. The fact that HEAD@ is translated to HEAD is just an implementation detail.

-- 
Felipe Contreras
Duy Nguyen· Apr 30, 2013, 06:17 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 32 quoted lines
> On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>>> use 'git show @~1', and all that goody goodness.
>>
>> I like this. I haven't spent a lot of time on thinking about
>> ambiguation. But I think we're safe there. '@' is not overloaded much
>> like ':', '^' or '~'.
>>
>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>>> 'master@'.
>>
>> I'm a bit reluctant to this. It looks like incomplete syntax to me as
>> '@' has always been followed by '{'. Can we have the lone '@' candy
>> but reject master@ and HEAD@? There's no actual gain in writing
>> master@ vs master@{0}.
>
> That's what I tried first, but it just didn't feel elegant to have one
> check for this case only. foo@ does follow naturally, and it doesn't
> hurt.
>
>>> +'@'::
>>> +  '@' alone is a shortcut for 'HEAD'
>>> +
>>
>> And this does not explain about HEAD@ or master@. But because I prefer
>> the candy part only. This documentation part looks good :)
>
> Yeah, there's no point in documenting things that are not useful for
> the user. The fact that HEAD@ is translated to HEAD is just an
> implementation detail.

Exactly. As it's implementation detail, it should not be exposed to user as "huh?" moments when they type "HEAD@". I'm may be paranoid, but if some user finds it nice (or just different) to try master@ in scripts, then we change implementation details and master@ no longer works, people could be upset. Undefined behavior syntax should be kept to minimum. And to answer your other mail regarding the harmlessness of @{-1}@, I'd rather pay some extra code than leave some loose ends like that. -- Duy

Felipe Contreras· Apr 30, 2013, 06:20 UTC · re: Duy Nguyen · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 1:17 AM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 43 quoted lines
> On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
>>> <felipe.contreras@gmail.com> wrote:
>>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>>>> use 'git show @~1', and all that goody goodness.
>>>
>>> I like this. I haven't spent a lot of time on thinking about
>>> ambiguation. But I think we're safe there. '@' is not overloaded much
>>> like ':', '^' or '~'.
>>>
>>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>>>> 'master@'.
>>>
>>> I'm a bit reluctant to this. It looks like incomplete syntax to me as
>>> '@' has always been followed by '{'. Can we have the lone '@' candy
>>> but reject master@ and HEAD@? There's no actual gain in writing
>>> master@ vs master@{0}.
>>
>> That's what I tried first, but it just didn't feel elegant to have one
>> check for this case only. foo@ does follow naturally, and it doesn't
>> hurt.
>>
>>>> +'@'::
>>>> +  '@' alone is a shortcut for 'HEAD'
>>>> +
>>>
>>> And this does not explain about HEAD@ or master@. But because I prefer
>>> the candy part only. This documentation part looks good :)
>>
>> Yeah, there's no point in documenting things that are not useful for
>> the user. The fact that HEAD@ is translated to HEAD is just an
>> implementation detail.
>
> Exactly. As it's implementation detail, it should not be exposed to
> user as "huh?" moments when they type "HEAD@". I'm may be paranoid,
> but if some user finds it nice (or just different) to try master@ in
> scripts, then we change implementation details and master@ no longer
> works, people could be upset. Undefined behavior syntax should be kept
> to minimum. And to answer your other mail regarding the harmlessness
> of @{-1}@, I'd rather pay some extra code than leave some loose ends
> like that.
I don't see it as a loose end.
Show changes to sha1_name.c +5 −1
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -443,8 +443,11 @@ static int get_sha1_basic(const char *str, int
len, unsigned char *sha1)
                return 0;

        empty_at = len && str[len-1] == '@';
-       if (empty_at)
+       if (empty_at) {
+               reflog_len = 0;
                len = len-1;
+               goto next;
+       }

        /* basic@{time or number or -number} format to query ref-log */
        reflog_len = at = 0;
@@ -460,6 +463,7 @@ static int get_sha1_basic(const char *str, int
len, unsigned char *sha1)
                }
        }

+next:
-- 
Felipe Contreras
Duy Nguyen· Apr 30, 2013, 06:30 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 11 quoted lines
>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>>> 'master@'.
>>
>> I'm a bit reluctant to this. It looks like incomplete syntax to me as
>> '@' has always been followed by '{'. Can we have the lone '@' candy
>> but reject master@ and HEAD@? There's no actual gain in writing
>> master@ vs master@{0}.
>
> That's what I tried first, but it just didn't feel elegant to have one
> check for this case only. foo@ does follow naturally, and it doesn't
> hurt.

I'd say it's a side effect. This would stop both @{-1}@ and master@. Whitespace corruption expected.

-- 8< --
Show changes to sha1_name.c +5 −3
diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..58bdb42 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -437,11 +437,13 @@ static int get_sha1_basic(const char *str, int
len, unsigned char *sha1)
        static const char *warn_msg = "refname '%.*s' is ambiguous.";
        char *real_ref = NULL;
        int refs_found = 0;
-       int at, reflog_len;
+       int at, reflog_len, short_head;

        if (len == 40 && !get_sha1_hex(str, sha1))
                return 0;

+       short_head = len == 1 && str[0] == '@';
+
        /* basic@{time or number or -number} format to query ref-log */
        reflog_len = at = 0;
        if (len && str[len-1] == '}') {
@@ -475,6 +477,8 @@ static int get_sha1_basic(const char *str, int
len, unsigned char *sha1)
                refs_found = dwim_ref("HEAD", 4, sha1, &real_ref);
        } else if (reflog_len)
                refs_found = dwim_log(str, len, sha1, &real_ref);
+       else if (short_head)
+               refs_found = dwim_ref("HEAD", 4, sha1, &real_ref);
        else
                refs_found = dwim_ref(str, len, sha1, &real_ref);

-- 8< --
--
Duy
Felipe Contreras· Apr 30, 2013, 07:55 UTC · re: Duy Nguyen · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 1:30 AM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 16 quoted lines
> On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>>>> 'master@'.
>>>
>>> I'm a bit reluctant to this. It looks like incomplete syntax to me as
>>> '@' has always been followed by '{'. Can we have the lone '@' candy
>>> but reject master@ and HEAD@? There's no actual gain in writing
>>> master@ vs master@{0}.
>>
>> That's what I tried first, but it just didn't feel elegant to have one
>> check for this case only. foo@ does follow naturally, and it doesn't
>> hurt.
>
> I'd say it's a side effect. This would stop both @{-1}@ and master@.
> Whitespace corruption expected.

Yeah, this is what I did first, but if since there's no relation with anything else, '@' could be any other character.

-- 
Felipe Contreras
Michael Haggerty· Apr 30, 2013, 07:09 UTC · re: Duy Nguyen · lore

Re: [PATCH] Add new @ shortcut for HEAD

On 04/30/2013 07:54 AM, Duy Nguyen wrote:
Show 16 quoted lines
> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>> use 'git show @~1', and all that goody goodness.
> 
> I like this. I haven't spent a lot of time on thinking about
> ambiguation. But I think we're safe there. '@' is not overloaded much
> like ':', '^' or '~'.
> 
>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>> 'master@'.
> 
> I'm a bit reluctant to this. It looks like incomplete syntax to me as
> '@' has always been followed by '{'. Can we have the lone '@' candy
> but reject master@ and HEAD@? There's no actual gain in writing
> master@ vs master@{0}.

According to git-check-ref-format(1), an "@" character is currently legal in a reference name as long as it is not followed by "{". As an example, git-svn uses "@" in reference names (e.g., "refs/remotes/svn/tags/foo@56945"), I believe when a Subversion branch or tag is deleted then re-created.

This is not to say that the rule can't be changed and/or that the git-svn use of such tag names conflicts with the proposed new syntax. But it can definitely not be excluded that the new pattern will be ambiguous with refnames that are already in use "in the wild".

Amusingly, it is already possible to define a reference or symbolic reference named "@". So all that you need to do is type

    git symbolic-ref -m "Create @ alias for HEAD" @ HEAD
to get the shortcut that you want :-)
Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Ramkumar Ramachandra· Apr 30, 2013, 07:35 UTC · re: Michael Haggerty · lore

Re: [PATCH] Add new @ shortcut for HEAD

Michael Haggerty wrote:
>     git symbolic-ref -m "Create @ alias for HEAD" @ HEAD

I find this very interesting. I already have a symbolic ref H pointing to HEAD, but it has some quirks: H@{u} complains that H is an invalid branch for example. When I create the symbolic-ref @, I'm not _exactly_ creating a synonym for HEAD: @{u} works, not @@{u}.

Many people are confused by this patch (reflog? HEAD@ versus master@? incomplete due to { omission?), and I'm not sure HEAD@ or master@ are even useful. This confusion can be avoided completely if the patch has the exact same effect as symbolic-ref'ing @ to HEAD.

Duy Nguyen· Apr 30, 2013, 10:16 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 2:35 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 7 quoted lines
> Michael Haggerty wrote:
>>     git symbolic-ref -m "Create @ alias for HEAD" @ HEAD
>
> I find this very interesting.  I already have a symbolic ref H
> pointing to HEAD, but it has some quirks: H@{u} complains that H is an
> invalid branch for example.  When I create the symbolic-ref @, I'm not
> _exactly_ creating a synonym for HEAD: @{u} works, not @@{u}.

Habits aside, why do you do H@{u} when @{u} is enough (and shorter)? -- Duy

Ramkumar Ramachandra· Apr 30, 2013, 11:10 UTC · re: Duy Nguyen · lore

Re: [PATCH] Add new @ shortcut for HEAD

Duy Nguyen wrote:
> Habits aside, why do you do H@{u} when @{u} is enough (and shorter)?

I don't. In the @{} spec, HEAD is implicit. My initial itch was that HEAD is not implicit in the ~<n> spec, and started off by thinking how we could make HEAD implicit specifically for that case [1]. Since then, we've realized that it's probably easier (and more useful) to have a synonym for HEAD that works in all specs. As a side effect, master..@ will work too. I was looking into the repercussions of this, and noticed that Michael's @ symref is not equivalent to my H symref. I previously thought that all symrefs would behave in exactly the same manner, but @ clearly seems to be a special case: I was merely pointing this out with an example.

[1]: http://article.gmane.org/gmane.comp.version-control.git/222343
Duy Nguyen· Apr 30, 2013, 10:12 UTC · re: Michael Haggerty · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 2:09 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 5 quoted lines
> According to git-check-ref-format(1), an "@" character is currently
> legal in a reference name as long as it is not followed by "{".  As an
> example, git-svn uses "@" in reference names (e.g.,
> "refs/remotes/svn/tags/foo@56945"), I believe when a Subversion branch
> or tag is deleted then re-created.
Thanks! I was looking for this document but couldn't remember its name.
Show 6 quoted lines
> Amusingly, it is already possible to define a reference or symbolic
> reference named "@".  So all that you need to do is type
>
>     git symbolic-ref -m "Create @ alias for HEAD" @ HEAD
>
> to get the shortcut that you want :-)

Not so amusingly (and off topic), why reading the code this patch touches, I think if we have a ref whose last component is exactly 40 chars and contains only [0-9a-fA-F], then we simply consider it sha-1 and return without reading the ref. -- Duy

Junio C Hamano· Apr 30, 2013, 17:22 UTC · re: Duy Nguyen · lore

Re: [PATCH] Add new @ shortcut for HEAD

Duy Nguyen <pclouds@gmail.com> writes:
Show 16 quoted lines
> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>> use 'git show @~1', and all that goody goodness.
>
> I like this. I haven't spent a lot of time on thinking about
> ambiguation. But I think we're safe there. '@' is not overloaded much
> like ':', '^' or '~'.
>
>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>> 'master@'.
>
> I'm a bit reluctant to this. It looks like incomplete syntax to me as
> '@' has always been followed by '{'. Can we have the lone '@' candy
> but reject master@ and HEAD@? There's no actual gain in writing
> master@ vs master@{0}.

Originally I was going to say the same, but after thinking about it a bit more, I changed my mind.

If you accept only "@" but not "master@", that behaviour needs a wrong world model to understand and justify (one of which is "@ is a synonym for HEAD"). If your rule is "In $anything@{$n}, you can drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0} becomes master@, and @{0} becomes @ naturally.

We should make sure that the code rejects "git update-ref @ foo" because that is "git update-ref @{0} ref", by the way. I didn't check with Felipe's patch.

>> +'@'::
>> +  '@' alone is a shortcut for 'HEAD'
>> +

I think this explanation sends a wrong message, hinting as if you can expect "update-ref @ master", "symbolic-ref @ refs/heads/next" etc. to do something sensible to HEAD.

Felipe's original justification in the log message "I want to drop {0}" sounds closer to what is going on here.

Ramkumar Ramachandra· Apr 30, 2013, 17:37 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

Junio C Hamano wrote:
Show 5 quoted lines
> If you accept only "@" but not "master@", that behaviour needs a
> wrong world model to understand and justify (one of which is "@ is a
> synonym for HEAD").  If your rule is "In $anything@{$n}, you can
> drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0}
> becomes master@, and @{0} becomes @ naturally.

You're telling me how to get @ from @{0}, but not how to get @ from HEAD. @{0}@{4} is meaningless, but HEAD@{4} is meaningful.

Ramkumar Ramachandra· Apr 30, 2013, 17:40 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

Junio C Hamano wrote:
Show 5 quoted lines
> If you accept only "@" but not "master@", that behaviour needs a
> wrong world model to understand and justify (one of which is "@ is a
> synonym for HEAD").  If your rule is "In $anything@{$n}, you can
> drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0}
> becomes master@, and @{0} becomes @ naturally.

Besides, you're going in the wrong direction this time. You are trying to fit an explanation to something that is useless. How is master@ useful?

Junio C Hamano· Apr 30, 2013, 17:56 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH] Add new @ shortcut for HEAD

Ramkumar Ramachandra <artagnon@gmail.com> writes:
Show 10 quoted lines
> Junio C Hamano wrote:
>> If you accept only "@" but not "master@", that behaviour needs a
>> wrong world model to understand and justify (one of which is "@ is a
>> synonym for HEAD").  If your rule is "In $anything@{$n}, you can
>> drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0}
>> becomes master@, and @{0} becomes @ naturally.
>
> Besides, you're going in the wrong direction this time.  You are
> trying to fit an explanation to something that is useless.  How is
> master@ useful?

How else would you explain why "rev-parse --symbolic-full-name @" does not make sense and "update-ref @" does not update HEAD?

Ramkumar Ramachandra· Apr 30, 2013, 18:04 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

Junio C Hamano wrote:
> How else would you explain why "rev-parse --symbolic-full-name @"
> does not make sense
It does make sense.  (Try it with my patch) [*1*]
> and "update-ref @" does not update HEAD?

Why should update-ref update HEAD? I'm asking it to update the symbolic-ref override .git/@.

[Footnote]

*1* I made a mistake in the commit message when I said that git symbolic-ref @ HEAD had the exact same effect.

Felipe Contreras· Apr 30, 2013, 18:20 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 12:40 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 10 quoted lines
> Junio C Hamano wrote:
>> If you accept only "@" but not "master@", that behaviour needs a
>> wrong world model to understand and justify (one of which is "@ is a
>> synonym for HEAD").  If your rule is "In $anything@{$n}, you can
>> drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0}
>> becomes master@, and @{0} becomes @ naturally.
>
> Besides, you're going in the wrong direction this time.  You are
> trying to fit an explanation to something that is useless.  How is
> master@ useful?

It's not. The same way master^0^0~4 is not useful, yet it's works; it's a logical result from the syntax.

-- 
Felipe Contreras
Ramkumar Ramachandra· Apr 30, 2013, 18:45 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras wrote:
> It's not. The same way master^0^0~4 is not useful, yet it's works;
> it's a logical result from the syntax.

It's logical if you explain @ as a shortcut for @{0}, and make @{0}@{1} resolve somehow [*1*].

[Footnotes]

*1*: The best I can do is @{0} is like a ref (while @{>0} are revisions), but you can't update-ref or symbolic-ref it. Kludgy, don't you think?

Felipe Contreras· Apr 30, 2013, 22:08 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 1:45 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 6 quoted lines
> Felipe Contreras wrote:
>> It's not. The same way master^0^0~4 is not useful, yet it's works;
>> it's a logical result from the syntax.
>
> It's logical if you explain @ as a shortcut for @{0}, and make
> @{0}@{1} resolve somehow [*1*].

But @{-1}@{1} does resolve, and so does @{u}@{1}. So @ would be a shortcut of @{this ref}, a no-op on the ref.

-- 
Felipe Contreras
Felipe Contreras· Apr 30, 2013, 17:47 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 12:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 31 quoted lines
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>>> use 'git show @~1', and all that goody goodness.
>>
>> I like this. I haven't spent a lot of time on thinking about
>> ambiguation. But I think we're safe there. '@' is not overloaded much
>> like ':', '^' or '~'.
>>
>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>>> 'master@'.
>>
>> I'm a bit reluctant to this. It looks like incomplete syntax to me as
>> '@' has always been followed by '{'. Can we have the lone '@' candy
>> but reject master@ and HEAD@? There's no actual gain in writing
>> master@ vs master@{0}.
>
> Originally I was going to say the same, but after thinking about it
> a bit more, I changed my mind.
>
> If you accept only "@" but not "master@", that behaviour needs a
> wrong world model to understand and justify (one of which is "@ is a
> synonym for HEAD").  If your rule is "In $anything@{$n}, you can
> drop {$n} when $n==0", then HEAD@{0} becomes HEAD@ and master@{0}
> becomes master@, and @{0} becomes @ naturally.
>
> We should make sure that the code rejects "git update-ref @ foo"
> because that is "git update-ref @{0} ref", by the way.  I didn't
> check with Felipe's patch.

Hmm, with or without my patch 'git update @ foo' does nothing, same with 'git update blah foo'. No error, no non-zero exit code, just doesn't do anything.

Show 7 quoted lines
>>> +'@'::
>>> +  '@' alone is a shortcut for 'HEAD'
>>> +
>
> I think this explanation sends a wrong message, hinting as if you
> can expect "update-ref @ master", "symbolic-ref @ refs/heads/next"
> etc. to do something sensible to HEAD.

Why would it? This is Documentation/revisions.txt, 'update-ref' has nothing to do with that.

This hints that the user can do "update-ref @" as much as the paragraph below thins that that user can do "update-ref master@{today}".

Cheers.
-- 
Felipe Contreras
Jeff King· Apr 30, 2013, 17:56 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 12:47:57PM -0500, Felipe Contreras wrote:
Show 7 quoted lines
> > We should make sure that the code rejects "git update-ref @ foo"
> > because that is "git update-ref @{0} ref", by the way.  I didn't
> > check with Felipe's patch.
> 
> Hmm, with or without my patch 'git update @ foo' does nothing, same
> with 'git update blah foo'. No error, no non-zero exit code, just
> doesn't do anything.
Are you sure?
  $ git version
  git version 1.8.2
  $ git update-ref @ foo
  fatal: foo: not a valid SHA1
  $ git update-ref @ origin/master
  $ echo $?
  0
  $ cat .git/@
  89740333e8d398f1da701e9023675321bbb9a85b
-Peff
Felipe Contreras· Apr 30, 2013, 18:18 UTC · re: Jeff King · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 12:56 PM, Jeff King <peff@peff.net> wrote:
Show 23 quoted lines
> On Tue, Apr 30, 2013 at 12:47:57PM -0500, Felipe Contreras wrote:
>
>> > We should make sure that the code rejects "git update-ref @ foo"
>> > because that is "git update-ref @{0} ref", by the way.  I didn't
>> > check with Felipe's patch.
>>
>> Hmm, with or without my patch 'git update @ foo' does nothing, same
>> with 'git update blah foo'. No error, no non-zero exit code, just
>> doesn't do anything.
>
> Are you sure?
>
>   $ git version
>   git version 1.8.2
>
>   $ git update-ref @ foo
>   fatal: foo: not a valid SHA1
>
>   $ git update-ref @ origin/master
>   $ echo $?
>   0
>   $ cat .git/@
>   89740333e8d398f1da701e9023675321bbb9a85b
Right. I don't know why I expected it to show in 'git show-ref'.
-- 
Felipe Contreras
Junio C Hamano· Apr 30, 2013, 19:42 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

Junio C Hamano <gitster@pobox.com> writes:
Show 21 quoted lines
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>>> use 'git show @~1', and all that goody goodness.
>>
>> I like this. I haven't spent a lot of time on thinking about
>> ambiguation. But I think we're safe there. '@' is not overloaded much
>> like ':', '^' or '~'.
>>
>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>>> 'master@'.
>>
>> I'm a bit reluctant to this. It looks like incomplete syntax to me as
>> '@' has always been followed by '{'. Can we have the lone '@' candy
>> but reject master@ and HEAD@? There's no actual gain in writing
>> master@ vs master@{0}.
>
> Originally I was going to say the same, but after thinking about it
> a bit more, I changed my mind.
Let me change my mind once again ;-)

As @ has been a valid character in a ref, I think "git show master@" and "git show HEAD@" _should_ error out, not because they suffix 'master' and 'HEAD" in a funny way, but simply because there is no branch called 'master@' (i.e. 'git for-each-ref | grep master@' yields empty). After you run "git branch master@ master~26", you should see "git show master@" not to error out, because that is just the name of a branch with somewhat an unusual name.

And we can still have "git show @" to do "git show HEAD", based on a world model completely different from I (incorrectly) advocated in the message I am replying to.

The rule would be "You should be able to say '@' where-ever you currently say HEAD" (aka '@' is a short-hand for 'HEAD').

That means "git checout @" should work the same way as "git checkout HEAD", "git log @~4" would work the same way as "git log HEAD~4", "git update-ref @ $(git rev-parse master)" should update the HEAD without creating $GIT_DIR/@, etc.

You can't go any simpler than that rule, and there is no room for confusion if that rule is properly implemented.

Hmm?
Ramkumar Ramachandra· Apr 30, 2013, 19:53 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

Junio C Hamano wrote:
> [...]
> You can't go any simpler than that rule, and there is no room for
> confusion if that rule is properly implemented.

In other words: the sequence "@" is short for "HEAD". Isn't that _exactly_ what I implemented in my two-liner?

However, I'm tilting towards respecting .git/@ as a manual override. Why? Because we'd have to either claim that git symbolic-ref @ HEAD is a noop, or deny it altogether (by saying that @ is not a valid symbolic ref). The latter approach obviously sounds more sensible, but I don't like unnecessarily eating up @.

Junio C Hamano· Apr 30, 2013, 20:05 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH] Add new @ shortcut for HEAD

Ramkumar Ramachandra <artagnon@gmail.com> writes:
> In other words: the sequence "@" is short for "HEAD".

That is saying a very different thing. master@{4.days} is not short for masterHEAD{4.days}.

> Isn't that
> _exactly_ what I implemented in my two-liner?
I dunno.  

As design and semantics look still fuzzy (the primary one I am not sure about is if @ is a ref or just a revision), even though the desire to have _something_ seem to be popular, I am not particulary interested in looking at an alternative patch. I want to see the right semantics first.

Ramkumar Ramachandra· Apr 30, 2013, 20:37 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

Junio C Hamano wrote:
Show 6 quoted lines
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> In other words: the sequence "@" is short for "HEAD".
>
> That is saying a very different thing.  master@{4.days} is not short
> for masterHEAD{4.days}.

I meant after ^, ~, @{} have been peeled off. Just before resolving what's left.

Show 5 quoted lines
> As design and semantics look still fuzzy (the primary one I am not
> sure about is if @ is a ref or just a revision), even though the
> desire to have _something_ seem to be popular, I am not particulary
> interested in looking at an alternative patch. I want to see the
> right semantics first.

I wanted to explain it through an implementation, but okay. In your proposal, @ is a special ref: it behaves like a ref in a rev spec, but cannot be update-ref'ed or symbolic-ref'ed. This is probably the best we can do, unless we want to emulate a full ref (I'm not sure how useful the .git/@ override will even be).

Junio C Hamano· Apr 30, 2013, 19:59 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

Junio C Hamano <gitster@pobox.com> writes:
Show 12 quoted lines
> The rule would be "You should be able to say '@' where-ever you
> currently say HEAD" (aka '@' is a short-hand for 'HEAD').
>
> That means "git checout @" should work the same way as "git checkout
> HEAD", "git log @~4" would work the same way as "git log HEAD~4",
> "git update-ref @ $(git rev-parse master)" should update the HEAD
> without creating $GIT_DIR/@, etc.
>
> You can't go any simpler than that rule, and there is no room for
> confusion if that rule is properly implemented.
>
> Hmm?

I personally would not mind an easier-to-implement rule that says "You can say '@' to mean HEAD^0, i.e. the object name of the commit at the tip of your current branch". That would make sure that nobody would expect "git update-ref @ $(git rev-parse master~4)" to work.

Felipe Contreras· Apr 30, 2013, 22:17 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 2:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 33 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
>>> <felipe.contreras@gmail.com> wrote:
>>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>>>> use 'git show @~1', and all that goody goodness.
>>>
>>> I like this. I haven't spent a lot of time on thinking about
>>> ambiguation. But I think we're safe there. '@' is not overloaded much
>>> like ':', '^' or '~'.
>>>
>>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>>>> 'master@'.
>>>
>>> I'm a bit reluctant to this. It looks like incomplete syntax to me as
>>> '@' has always been followed by '{'. Can we have the lone '@' candy
>>> but reject master@ and HEAD@? There's no actual gain in writing
>>> master@ vs master@{0}.
>>
>> Originally I was going to say the same, but after thinking about it
>> a bit more, I changed my mind.
>
> Let me change my mind once again ;-)
>
> As @ has been a valid character in a ref, I think "git show master@"
> and "git show HEAD@" _should_ error out, not because they suffix
> 'master' and 'HEAD" in a funny way, but simply because there is no
> branch called 'master@' (i.e. 'git for-each-ref | grep master@'
> yields empty).  After you run "git branch master@ master~26", you
> should see "git show master@" not to error out, because that is just
> the name of a branch with somewhat an unusual name.

There is also no branch named master@{0}. And there are no branches with @{ in them, because we forbid them. So the question is what do we want to forbid? If we don't want to forbid 'master@', then sure 'master@' should not evaluate to 'master'.

Show 14 quoted lines
> And we can still have "git show @" to do "git show HEAD", based on a
> world model completely different from I (incorrectly) advocated in
> the message I am replying to.
>
> The rule would be "You should be able to say '@' where-ever you
> currently say HEAD" (aka '@' is a short-hand for 'HEAD').
>
> That means "git checout @" should work the same way as "git checkout
> HEAD", "git log @~4" would work the same way as "git log HEAD~4",
> "git update-ref @ $(git rev-parse master)" should update the HEAD
> without creating $GIT_DIR/@, etc.
>
> You can't go any simpler than that rule, and there is no room for
> confusion if that rule is properly implemented.

I disagree. I can do 'git log @{-1}-4', but I cannot do 'git update-ref @{-1}'. Why? Because the '@' notation is for revision parsing, and 'git update-ref' doesn't do revision parsing.

I'd say, everywhere where you could do @{-1}, you should be able to do @.
Cheers.
-- 
Felipe Contreras
Junio C Hamano· Apr 30, 2013, 22:27 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 13 quoted lines
>> That means "git checout @" should work the same way as "git checkout
>> HEAD", "git log @~4" would work the same way as "git log HEAD~4",
>> "git update-ref @ $(git rev-parse master)" should update the HEAD
>> without creating $GIT_DIR/@, etc.
>>
>> You can't go any simpler than that rule, and there is no room for
>> confusion if that rule is properly implemented.
>
> I disagree. I can do 'git log @{-1}-4', but I cannot do 'git
> update-ref @{-1}'. Why? Because the '@' notation is for revision
> parsing, and 'git update-ref' doesn't do revision parsing.
>
> I'd say, everywhere where you could do @{-1}, you should be able to do @.

Yes, @{-1} is about a ref, the branch that you were on previously. That is why you can do

	git checkout fc/at-head
        git checkout master...
        git am -s <./+fc-updated-at-head-series.mbox
        git co -B @{-1}

We wouldn't be able to do the last step, if @{-1} evaluated it down to the object name, losing the refname.

If "update-ref @{-1}" does not grok @{-1}, probably there needs a call to interpret_nth_prior_checkout() in the codepath.

Felipe Contreras· Apr 30, 2013, 22:38 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 5:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 29 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> That means "git checout @" should work the same way as "git checkout
>>> HEAD", "git log @~4" would work the same way as "git log HEAD~4",
>>> "git update-ref @ $(git rev-parse master)" should update the HEAD
>>> without creating $GIT_DIR/@, etc.
>>>
>>> You can't go any simpler than that rule, and there is no room for
>>> confusion if that rule is properly implemented.
>>
>> I disagree. I can do 'git log @{-1}-4', but I cannot do 'git
>> update-ref @{-1}'. Why? Because the '@' notation is for revision
>> parsing, and 'git update-ref' doesn't do revision parsing.
>>
>> I'd say, everywhere where you could do @{-1}, you should be able to do @.
>
> Yes, @{-1} is about a ref, the branch that you were on previously.
> That is why you can do
>
>         git checkout fc/at-head
>         git checkout master...
>         git am -s <./+fc-updated-at-head-series.mbox
>         git co -B @{-1}
>
> We wouldn't be able to do the last step, if @{-1} evaluated it down
> to the object name, losing the refname.
>
> If "update-ref @{-1}" does not grok @{-1}, probably there needs a
> call to interpret_nth_prior_checkout() in the codepath.

Maybe, but the closest thing would be dwim_ref(), which would also use rev parsing rules, so there might ambiguous refs.

Since 'update-ref master' updates the 'master' ref, and not 'refs/heads/master' (IOW; no parsing at all), I think it makes sense that @{-1} is not parsed, and neither is @.

If the user really really wants rev parsing, she can use 'git rev-parse'.
Cheers.
-- 
Felipe Contreras
Junio C Hamano· Apr 30, 2013, 22:42 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras <felipe.contreras@gmail.com> writes:
> Since 'update-ref master' updates the 'master' ref, and not
> 'refs/heads/master' (IOW; no parsing at all), I think it makes sense
> that @{-1} is not parsed, and neither is @.
That is a very valid point.
What should "rev-parse --symbolic-full-name @" say?
Felipe Contreras· Apr 30, 2013, 22:53 UTC · re: Junio C Hamano · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 5:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Since 'update-ref master' updates the 'master' ref, and not
>> 'refs/heads/master' (IOW; no parsing at all), I think it makes sense
>> that @{-1} is not parsed, and neither is @.
>
> That is a very valid point.
>
> What should "rev-parse --symbolic-full-name @" say?

Probably the same as 'rev-parse --symbolic-full-name HEAD' (it doesn't with my patch).

-- 
Felipe Contreras
Felipe Contreras· Apr 30, 2013, 23:00 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 5:53 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 13 quoted lines
> On Tue, Apr 30, 2013 at 5:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> Since 'update-ref master' updates the 'master' ref, and not
>>> 'refs/heads/master' (IOW; no parsing at all), I think it makes sense
>>> that @{-1} is not parsed, and neither is @.
>>
>> That is a very valid point.
>>
>> What should "rev-parse --symbolic-full-name @" say?
>
> Probably the same as 'rev-parse --symbolic-full-name HEAD' (it doesn't
> with my patch).
The gist of my patch can be dropped, this does the trick:
Show changes to sha1_name.c +21 −0
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -965,6 +965,21 @@ int get_sha1_mb(const char *name, unsigned char *sha1)
        return st;
 }

+static int interpret_empty_at(const char *name, int namelen, int len,
struct strbuf *buf)
+{
+       if (namelen - len < 1 || name[len + 1] == '{')
+               return -1;
+
+       strbuf_reset(buf);
+       if (len == 0) {
+               strbuf_add(buf, "HEAD", 4);
+               return 1;
+       } else {
+               strbuf_add(buf, name, len);
+               return len + 1;
+       }
+}
+
 static int reinterpret(const char *name, int namelen, int len, struct
strbuf *buf)
 {
        /* we have extra data, which might need further processing */
@@ -1025,9 +1040,15 @@ int interpret_branch_name(const char *name,
struct strbuf *buf)
        cp = strchr(name, '@');
        if (!cp)
                return -1;
+
+       len = interpret_empty_at(name, namelen, cp - name, buf);
+       if (len > 0)
+               return reinterpret(name, namelen, len, buf);
+
        tmp_len = upstream_mark(cp, namelen - (cp - name));
        if (!tmp_len)
                return -1;
+
        len = cp + tmp_len - name;
        cp = xstrndup(name, cp - name);
        upstream = branch_get(*cp ? cp : NULL);
-- 
Felipe Contreras
Felipe Contreras· Apr 30, 2013, 23:19 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 6:00 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 15 quoted lines
> +static int interpret_empty_at(const char *name, int namelen, int len,
> struct strbuf *buf)
> +{
> +       if (namelen - len < 1 || name[len + 1] == '{')
> +               return -1;
> +
> +       strbuf_reset(buf);
> +       if (len == 0) {
> +               strbuf_add(buf, "HEAD", 4);
> +               return 1;
> +       } else {
> +               strbuf_add(buf, name, len);
> +               return len + 1;
> +       }
> +}

Hmm, it's not correct, and besides, if we don't parse 'master@', it's much simpler:

/* parse @something syntax, when 'something' is not {.*} */
static int interpret_empty_at(const char *name, int namelen, int len,
struct strbuf *buf)
{
	if (len || (namelen > 1 && name[1] == '{'))
		return -1;
	strbuf_reset(buf);
	strbuf_add(buf, "HEAD", 4);
	return 1;
}
-- 
Felipe Contreras
Junio C Hamano· Apr 30, 2013, 23:24 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 33 quoted lines
> On Tue, Apr 30, 2013 at 6:00 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>
>> +static int interpret_empty_at(const char *name, int namelen, int len,
>> struct strbuf *buf)
>> +{
>> +       if (namelen - len < 1 || name[len + 1] == '{')
>> +               return -1;
>> +
>> +       strbuf_reset(buf);
>> +       if (len == 0) {
>> +               strbuf_add(buf, "HEAD", 4);
>> +               return 1;
>> +       } else {
>> +               strbuf_add(buf, name, len);
>> +               return len + 1;
>> +       }
>> +}
>
> Hmm, it's not correct, and besides, if we don't parse 'master@', it's
> much simpler:
>
> /* parse @something syntax, when 'something' is not {.*} */
> static int interpret_empty_at(const char *name, int namelen, int len,
> struct strbuf *buf)
> {
> 	if (len || (namelen > 1 && name[1] == '{'))
> 		return -1;
>
> 	strbuf_reset(buf);
> 	strbuf_add(buf, "HEAD", 4);
> 	return 1;
> }

I'm done with today's integration cycle and pushed the series without these updates out on 'pu'. Hopefully you will have a "drop the last N and replace them with this" update after finishing these experiments by tomorrow? ;-)

Thanks.

People who wanted to see some form of typesaver for HEAD, please poke at the implementation and see if there are cases where @ should be interpreted as HEAD replacement but isn't (or vice-versa).

Duy Nguyen· Apr 30, 2013, 06:07 UTC · re: Felipe Contreras · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 8 quoted lines
> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>
> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
> 'master@'.
>
> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
> use 'git show @~1', and all that goody goodness.

This patch also allows funny things like @{-1}@ (wanted to try the cute syntax @{u}@ but too lazy to setup upstream)

$ ./git rev-parse @{-1} 7e6a0cc47da79dd22c0338aee8750fda92ced5d9 $ ./git rev-parse @{-1}@ 7e6a0cc47da79dd22c0338aee8750fda92ced5d9 $ ./git rev-parse @{-1}@{0} @{-1}@{0} fatal: ambiguous argument '@{-1}@{0}': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' -- Duy

Felipe Contreras· Apr 30, 2013, 06:11 UTC · re: Duy Nguyen · lore

Re: [PATCH] Add new @ shortcut for HEAD

On Tue, Apr 30, 2013 at 1:07 AM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 13 quoted lines
> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>>
>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>> 'master@'.
>>
>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>> use 'git show @~1', and all that goody goodness.
>
> This patch also allows funny things like @{-1}@ (wanted to try the
> cute syntax @{u}@ but too lazy to setup upstream)

Yeah, I thought about that, and I thought it was harmless. Specially considering that doing anything else would be less elegant code-wise.

Cheers.
-- 
Felipe Contreras

← back to recent threads