Re: [PATCH v2 5/6] Add new @ shortcut for HEAD
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:57:05
Felipe Contreras [off-list ref] writes:
quoted hunk
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', which leaves us with @{0}, but we can't remove '{0}'? This patch allows '@' to be the same as 'HEAD'. So now we can use 'git show @~1', and all that goody goodness. Until now '@' was a valid name, but it conflicts with this idea, so lets make it invalid. Very few people if any probably used this name, if they did, they can rename it by using the full-path (e.g. refs/heads/@). Signed-off-by: Felipe Contreras <redacted> --- Documentation/git-check-ref-format.txt | 2 ++ Documentation/revisions.txt | 3 +++ refs.c | 4 ++++ sha1_name.c | 6 +++++- t/t1508-at-combinations.sh | 3 +++ 5 files changed, 17 insertions(+), 1 deletion(-)diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index ec1739a..e8035ec 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt@@ -54,6 +54,8 @@ Git imposes the following rules on how references are named: . They cannot contain a sequence `@{`. +. They cannot be the single character `@`. + . They cannot contain a `\`. These rules make it easy for shell script based tools to parsediff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index d477b3f..09896a3 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 bracediff --git a/refs.c b/refs.c index de2d8eb..4e70b3e 100644 --- a/refs.c +++ b/refs.c@@ -72,6 +72,10 @@ int check_refname_format(const char *refname, int flags) { int component_len, component_count = 0; + if (!strcmp(refname, "@")) + /* Refname is a single character '@'. */ + return -1;
This checks the single character "@" which is consistent with the documentation update, but does not seem to mesh well with "they can rename it by using the full-path refs/heads/@". I do not personally think it is wrong to end the log message with "if they did, too bad.", though ;-).