On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
<[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
