[PATCH] Add new @ shortcut for HEAD

[PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

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(-)

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

Re: [PATCH] Add new @ shortcut for HEAD

[Ramkumar Ramachandra]

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.

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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.

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Mon, Apr 29, 2013 at 3:01 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}'?
>>
>> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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).

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Mon, Apr 29, 2013 at 3:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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.

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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.

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

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}.

-- 
Felipe Contreras

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Mon, Apr 29, 2013 at 3:23 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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.

Re: [PATCH] Add new @ shortcut for HEAD

[Jonathan Nieder]

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".

Which works fine here.

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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).

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 12:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

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

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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?  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}.

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

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.

> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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:

> 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(-)

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

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Mon, Apr 29, 2013 at 6:06 PM, Junio C Hamano <gitster@pobox.com> wrote:

> --- 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

Re: [PATCH] Add new @ shortcut for HEAD

[Duy Nguyen]

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

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

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.

-- 
Felipe Contreras

Re: [PATCH] Add new @ shortcut for HEAD

[Duy Nguyen]

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.
--
Duy

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 1:17 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> 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.

--- 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

Re: [PATCH] Add new @ shortcut for HEAD

[Duy Nguyen]

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.

-- 8< --
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

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 1:30 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Michael Haggerty]

On 04/30/2013 07:54 AM, Duy Nguyen 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}.

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/

Re: [PATCH] Add new @ shortcut for HEAD

[Ramkumar Ramachandra]

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.

Re: [PATCH] Add new @ shortcut for HEAD

[Duy Nguyen]

On Tue, Apr 30, 2013 at 2:35 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Ramkumar Ramachandra]

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

Re: [PATCH] Add new @ shortcut for HEAD

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> I'm not
> _exactly_ creating a synonym for HEAD: @{u} works, not @@{u}.

Turns out this is actually a parsing-bug in @{u}.  @@{5.minutes.ago}
and @@{5} work just fine.

Re: [PATCH] Add new @ shortcut for HEAD

[Duy Nguyen]

On Tue, Apr 30, 2013 at 2:09 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> 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.

> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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.

>> +'@'::
>> +  '@' 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.

Re: [PATCH] Add new @ shortcut for HEAD

[Ramkumar Ramachandra]

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.

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.

Re: [PATCH] Add new @ shortcut for HEAD

[Ramkumar Ramachandra]

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?

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> 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?

Re: [PATCH] Add new @ shortcut for HEAD

[Ramkumar Ramachandra]

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.

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 12:40 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Ramkumar Ramachandra]

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?

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 1:45 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 12:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

>>> +'@'::
>>> +  '@' 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

Re: [PATCH] Add new @ shortcut for HEAD

[Jeff King]

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

-Peff

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 12:56 PM, Jeff King <peff@peff.net> wrote:
> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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.

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?

Re: [PATCH] Add new @ shortcut for HEAD

[Ramkumar Ramachandra]

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 @.

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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.

Re: [PATCH] Add new @ shortcut for HEAD

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> 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.

> 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).

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> 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.

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 2:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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'.

> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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.

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 5:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

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?

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

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).

-- 
Felipe Contreras

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 5:53 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> 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:

--- 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

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

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;
}

-- 
Felipe Contreras

Re: [PATCH] Add new @ shortcut for HEAD

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> 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).

Re: [PATCH] Add new @ shortcut for HEAD

[Duy Nguyen]

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)

$ ./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

Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras]

On Tue, Apr 30, 2013 at 1:07 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> 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