{"thread":{"id":"33681","subject":"[PATCH] refs.c: interpret @ as HEAD","startedAt":"2013-04-30T12:24:45Z","lastAt":"2013-05-01T08:35:00Z","messageCount":21,"participants":["Ramkumar Ramachandra","Duy Nguyen","Thomas Rast","Michael Haggerty","Junio C Hamano","Felipe Contreras"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"215985","messageId":"1367324685-22788-1-git-send-email-artagnon@gmail.com","threadId":"33681","inReplyTo":null,"subject":"[PATCH] refs.c: interpret @ as HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T12:24:45Z","receivedAt":"2013-04-30T12:24:45Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"The rev spec forms @{}, .., ... fill in HEAD as the missing argument\nautomatically. Unfortunately, HEAD~ is a very common idiom and\nthere is no way to make HEAD implicit here (due the shell expansion of\n~).\n\nHowever, there is an alternative solution to the issue: overload the\ncharacter @ to mean HEAD. Do this at the lowest possible layer of\nabstraction: in dwim_ref(), substitute @ with HEAD just before calling\nresolve_ref_unsafe(). The program will only reach this point after\nthe other specs like ~, ^ and @{} have been resolved; therefore, it is\nsafe to do it here.\n\nThis patch has the exact same effect as:\n\n $ git symbolic-ref @ HEAD\n\nIt means that you can now do @~1, @^2, and even topic..@. However,\nsince the @-parsing happens before we ever reach the symref\nresolution, @@{u} is invalid. But this is okay, since @{u} already\nhas an implicit HEAD in it.\n\nInspired-by: Felipe Contreras \nInspired-by: Michael Haggerty \nSigned-off-by: Ramkumar Ramachandra \n---\n I haven't included documentation/ tests because I want feedback on\n this two-liner first.\n\n refs.c | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/refs.c b/refs.c\nindex de2d8eb..cb67b73 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -1604,6 +1604,8 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)\n \n \t\tthis_result = refs_found ? sha1_from_ref : sha1;\n \t\tmksnpath(fullref, sizeof(fullref), *p, len, str);\n+\t\tif (!strcmp(fullref, \"@\"))\n+\t\t\tmksnpath(fullref, sizeof(fullref), *p, 4, \"HEAD\");\n \t\tr = resolve_ref_unsafe(fullref, this_result, 1, &flag);\n \t\tif (r) {\n \t\t\tif (!refs_found++)\n-- \n1.8.2.1.628.gcd33b41.dirty\n"},{"id":"215986","messageId":"CACsJy8C7vcxTkzmfABSykMxeX+68rWnr-Ohfhb3oMPi=Q5Tg6g@mail.gmail.com","threadId":"33681","inReplyTo":"1367324685-22788-1-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-30T12:31:28Z","receivedAt":"2013-04-30T12:31:28Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Apr 30, 2013 at 7:24 PM, Ramkumar Ramachandra\n wrote:\n> The rev spec forms @{}, .., ... fill in HEAD as the missing argument\n> automatically. Unfortunately, HEAD~ is a very common idiom and\n> there is no way to make HEAD implicit here (due the shell expansion of\n> ~).\n>\n> However, there is an alternative solution to the issue: overload the\n> character @ to mean HEAD. Do this at the lowest possible layer of\n> abstraction: in dwim_ref(), substitute @ with HEAD just before calling\n> resolve_ref_unsafe(). The program will only reach this point after\n> the other specs like ~, ^ and @{} have been resolved; therefore, it is\n> safe to do it here.\n>\n> This patch has the exact same effect as:\n>\n> $ git symbolic-ref @ HEAD\n>\n> It means that you can now do @~1, @^2, and even topic..@. However,\n> since the @-parsing happens before we ever reach the symref\n> resolution, @@{u} is invalid. But this is okay, since @{u} already\n> has an implicit HEAD in it.\n>\n> Inspired-by: Felipe Contreras \n> Inspired-by: Michael Haggerty \n> Signed-off-by: Ramkumar Ramachandra \n> ---\n> I haven't included documentation/ tests because I want feedback on\n> this two-liner first.\n\nYou need more than that :) As Michael pointed out '@' is a perfectly\nvalid ref name. If you do this, you need to reject '@' as invalid ref\nname. I guess another two lines in check_refname_format. But let's\nwait for more feedback first.\n--\nDuy\n"},{"id":"215988","messageId":"87zjwguq8t.fsf@linux-k42r.v.cablecom.net","threadId":"33681","inReplyTo":"1367324685-22788-1-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-04-30T13:01:22Z","receivedAt":"2013-04-30T13:01:22Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> The rev spec forms @{}, .., ... fill in HEAD as the missing argument\n> automatically. Unfortunately, HEAD~ is a very common idiom and\n> there is no way to make HEAD implicit here (due the shell expansion of\n> ~).\n>\n> However, there is an alternative solution to the issue: overload the\n> character @ to mean HEAD. Do this at the lowest possible layer of\n> abstraction: in dwim_ref(), substitute @ with HEAD just before calling\n> resolve_ref_unsafe(). The program will only reach this point after\n> the other specs like ~, ^ and @{} have been resolved; therefore, it is\n> safe to do it here.\n>\n> This patch has the exact same effect as:\n>\n> $ git symbolic-ref @ HEAD\n\nBut then why don't you just 'git symbolic-ref H HEAD' for a sort of\n\"local alias\"?\n\nWhat annoys me more is that there's no way to say\n\n git symbolic-ref U @{u}\n\nso that I can avoid that -- it's really clumsy to type on a Swiss German\nkeyboard. We'd need some sort of ref-alias feature for that to work.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"215990","messageId":"CALkWK0kx28+bfBYZ8bGyDoQ_+2bVVbeqvZ8DK7qe_ZVyVsBVtw@mail.gmail.com","threadId":"33681","inReplyTo":"87zjwguq8t.fsf@linux-k42r.v.cablecom.net","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T13:32:38Z","receivedAt":"2013-04-30T13:32:38Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Thomas Rast wrote:\n> But then why don't you just 'git symbolic-ref H HEAD' for a sort of\n> \"local alias\"?\n\nYes, I already have @ pointing to HEAD. And I think it's much nicer\nthan H (also since H@{u} doesn't resolve [1]). The purpose of this\npatch is to standardize @ for everyone.\n\n> What annoys me more is that there's no way to say\n>\n> git symbolic-ref U @{u}\n\nThat's because the part after \"ref: \" in a symref is expected to point\nto a concrete ref, and doesn't go through the get_sha1_basic()\nmachinery. Making symrefs peel recursively might or might not be a\ngood idea; I haven't thought about it enough. However, it's not my\nitch: write a patch and start a discussion?\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/222852/focus=222916\n"},{"id":"215992","messageId":"20130430150430.GA13398@lanh","threadId":"33681","inReplyTo":"87zjwguq8t.fsf@linux-k42r.v.cablecom.net","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-30T15:04:31Z","receivedAt":"2013-04-30T15:04:31Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Apr 30, 2013 at 03:01:22PM +0200, Thomas Rast wrote:\n> > This patch has the exact same effect as:\n> >\n> > $ git symbolic-ref @ HEAD\n> \n> But then why don't you just 'git symbolic-ref H HEAD' for a sort of\n> \"local alias\"?\n\nFor me, it's because I don't want to do that on every repo. One day if\nI change my mind and make P the new alias, i'll need to update every\nrepo again.\n\n> \n> What annoys me more is that there's no way to say\n> \n> git symbolic-ref U @{u}\n> \n> so that I can avoid that -- it's really clumsy to type on a Swiss German\n> keyboard. We'd need some sort of ref-alias feature for that to work.\n\nIt's not hard to do. The below patch makes \".\" equivalent to HEAD and\n\".U\" -> \"@{u}\". Refs are not supposed to have '.' at the beginning, so\nit's easy to figure somebody is using alias from what they send\nyou. Supporting refalias.* config should be easy.\n\n-- 8< --\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 3820f28..7842147 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -1239,6 +1239,27 @@ static char *resolve_relative_path(const char *rel)\n \t\t\t rel);\n }\n \n+static int get_sha1_with_alias(const char *name, int namelen,\n+\t\t\t unsigned char *sha1, int flags)\n+{\n+\tint ret;\n+\tstruct strbuf sb = STRBUF_INIT;\n+\tint alias_len = strcspn(name, \"@^~:\");\n+\tif (alias_len > namelen)\n+\t\talias_len = namelen;\n+\n+\tif (alias_len == 0)\t/* '.' is equal to HEAD */\n+\t\tstrbuf_addstr(&sb, \"HEAD\");\n+\telse if (alias_len == 1 && !strncmp(name, \"U\", 1))\n+\t\tstrbuf_addstr(&sb, \"@{u}\");\n+\telse\n+\t\treturn error(\"unknown alias %.*s\", alias_len, name);\n+\tstrbuf_addstr(&sb, name + alias_len);\n+\tret = get_sha1_1(sb.buf, sb.len, sha1, flags);\n+\tstrbuf_release(&sb);\n+\treturn ret;\n+}\n+\n static int get_sha1_with_context_1(const char *name,\n \t\t\t\t unsigned flags,\n \t\t\t\t const char *prefix,\n@@ -1252,6 +1273,8 @@ static int get_sha1_with_context_1(const char *name,\n \n \tmemset(oc, 0, sizeof(*oc));\n \toc->mode = S_IFINVALID;\n+\tif (name[0] == '.')\n+\t\treturn get_sha1_with_alias(name + 1, namelen - 1, sha1, flags);\n \tret = get_sha1_1(name, namelen, sha1, flags);\n \tif (!ret)\n \t\treturn ret;\n-- 8< --\n"},{"id":"215995","messageId":"517FEC9B.7020000@alum.mit.edu","threadId":"33681","inReplyTo":"20130430150430.GA13398@lanh","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-04-30T16:08:59Z","receivedAt":"2013-04-30T16:08:59Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 04/30/2013 05:04 PM, Duy Nguyen wrote:\n> On Tue, Apr 30, 2013 at 03:01:22PM +0200, Thomas Rast wrote:\n>> What annoys me more is that there's no way to say\n>>\n>> git symbolic-ref U @{u}\n>>\n>> so that I can avoid that -- it's really clumsy to type on a Swiss German\n>> keyboard. We'd need some sort of ref-alias feature for that to work.\n> \n> It's not hard to do. The below patch makes \".\" equivalent to HEAD and\n> \".U\" -> \"@{u}\". Refs are not supposed to have '.' at the beginning, so\n> it's easy to figure somebody is using alias from what they send\n> you. Supporting refalias.* config should be easy.\n\nSo what does \"git log master...U\" mean?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"215996","messageId":"7vehdsf19m.fsf@alter.siamese.dyndns.org","threadId":"33681","inReplyTo":"20130430150430.GA13398@lanh","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T16:09:57Z","receivedAt":"2013-04-30T16:09:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> It's not hard to do. The below patch makes \".\" equivalent to HEAD and\n> \".U\" -> \"@{u}\". Refs are not supposed to have '.' at the beginning, so\n> it's easy ...\n\nHow is the equivalent of master..@{u} expressed? master...U? How is\nit disambiguated from a symmetric difference between master and U?\n\nThere are reasons why some characters are forbidden from appearing\nat certain places in refname component. Anybody who designs a new\nsyntax needs to think _why_.\n\nThe restriction that a @ in refname cannot be followed by { is for\nthe same kind of disambiguation. I do not mind a way to spell HEAD\nwith shorter than 4 keystrokes, and as I said I suspect \"@\" may be\nthe least bad one among what people may come up with in this thread,\nbut I do not think we can explain it as \"@ is a synonym to HEAD\"\n[*1*]. We need to see if we can make the explanation we will give\nto end users is understandable.\n\n\n[Footnote]\n\n*1* I do not think \"@ is a new synonym for HEAD\" would not be a good\nexplanation. Some questions you should ask yourselves to see why:\n\n\"git update-ref HEAD $commit\" is accepted. If @ is a synonym for\nHEAD, \"git update-ref @ $commit\" should work exactly the same way,\nbut is it desirable? Would we have $GIT_DIR/@ as the result? How\nabout \"git symbolic-ref\"? Would @@{4} and HEAD@{4} be the same?\n"},{"id":"215999","messageId":"CACsJy8B3PpzidvAHado=y3ZromzROidmHh_OW9ZCOoFegzmQ3Q@mail.gmail.com","threadId":"33681","inReplyTo":"7vehdsf19m.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-30T16:26:44Z","receivedAt":"2013-04-30T16:26:44Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Apr 30, 2013 at 11:09 PM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n>\n>> It's not hard to do. The below patch makes \".\" equivalent to HEAD and\n>> \".U\" -> \"@{u}\". Refs are not supposed to have '.' at the beginning, so\n>> it's easy ...\n>\n> How is the equivalent of master..@{u} expressed? master...U? How is\n> it disambiguated from a symmetric difference between master and U?\n>\n> There are reasons why some characters are forbidden from appearing\n> at certain places in refname component. Anybody who designs a new\n> syntax needs to think _why_.\n\nI figured it had something to do with hidden filenames, not \"..\".\nThere's only one char left for ref alias, the leading forward slash.\nBut than opens another can of worms.. We could put still ref aliases\ninto the same ref namespace, with lower precedence that actual refs,\nso no new syntax required.\n--\nDuy\n"},{"id":"216005","messageId":"CALkWK0mK9uW-Z7YfUY_Ms1WO9vkEKRV31H5dqAOFgb_7SrDG+w@mail.gmail.com","threadId":"33681","inReplyTo":"7vehdsf19m.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T17:07:52Z","receivedAt":"2013-04-30T17:07:52Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> We need to see if we can make the explanation we will give\n> to end users is understandable.\n\nI'll make an attempt.\n\n@ can be used in two contexts:\n1. When used without the {}, it means HEAD.\n2. When used with a {}, it means what those three forms individually\nmean. @{} already implies HEAD: don't put an extra @.\n\nI think it's the cleanest.\n"},{"id":"216006","messageId":"CALkWK0nnmzV0dcZ9avO9zDPhnQh9wkF7stA77cNycoXfecfUuw@mail.gmail.com","threadId":"33681","inReplyTo":"CACsJy8B3PpzidvAHado=y3ZromzROidmHh_OW9ZCOoFegzmQ3Q@mail.gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T17:15:08Z","receivedAt":"2013-04-30T17:15:08Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Duy Nguyen wrote:\n> We could put still ref aliases\n> into the same ref namespace, with lower precedence that actual refs,\n> so no new syntax required.\n\nActually, ref-alises are the right way to solve the problem.\nRecursive symref peeling is a bad idea: I can't take my aliases with\nme, and they complicate unnecessarily.\n\nAny thoughts on how to implement it? Should it go as deep as\nresolve_ref_unsafe()?\n"},{"id":"216008","messageId":"CALkWK0kzjg+CPw8hq6ZAZxqVGdp7cf6HN-XHFCjbkNk9O=M5CA@mail.gmail.com","threadId":"33681","inReplyTo":"7vehdsf19m.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T17:23:04Z","receivedAt":"2013-04-30T17:23:04Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> \"git update-ref HEAD $commit\" is accepted. If @ is a synonym for\n> HEAD, \"git update-ref @ $commit\" should work exactly the same way,\n> but is it desirable?\n\n> Would we have $GIT_DIR/@ as the result? How\n> about \"git symbolic-ref\"?\n\nYes, it is a valid refname that can be overridden [*1*].\n\n> Would @@{4} and HEAD@{4} be the same?\n\nNo. Why should they?\n\n[Footnotes]\n\n*1*: In the current implementation, git update-ref fails.\n"},{"id":"216010","messageId":"CAMP44s0=5KniGDnVtKPg5sp=G8M-mPcq+Mu1nXqODfhT-MaNyg@mail.gmail.com","threadId":"33681","inReplyTo":"CALkWK0kzjg+CPw8hq6ZAZxqVGdp7cf6HN-XHFCjbkNk9O=M5CA@mail.gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T17:28:15Z","receivedAt":"2013-04-30T17:28:15Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 12:23 PM, Ramkumar Ramachandra\n wrote:\n> Junio C Hamano wrote:\n\n>> Would @@{4} and HEAD@{4} be the same?\n>\n> No. Why should they?\n\nWhy would HEAD^0^0~4 work? Because the syntax is recursive.\n\n-- \nFelipe Contreras\n"},{"id":"216011","messageId":"CALkWK0kLZ9WLVcPBWuQZCjOku4A+WQ7=YeooPmKGpk9HuGYQnw@mail.gmail.com","threadId":"33681","inReplyTo":"CAMP44s0=5KniGDnVtKPg5sp=G8M-mPcq+Mu1nXqODfhT-MaNyg@mail.gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T17:32:22Z","receivedAt":"2013-04-30T17:32:22Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> Why would HEAD^0^0~4 work? Because the syntax is recursive.\n\nThat's because you can compose with ^ and ^, while you can't with @\nand @. Does @{0}@{0} resolve?\n"},{"id":"216032","messageId":"7vwqrjdh6v.fsf@alter.siamese.dyndns.org","threadId":"33681","inReplyTo":"CALkWK0kLZ9WLVcPBWuQZCjOku4A+WQ7=YeooPmKGpk9HuGYQnw@mail.gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T18:08:56Z","receivedAt":"2013-04-30T18:08:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Felipe Contreras wrote:\n>> Why would HEAD^0^0~4 work? Because the syntax is recursive.\n>\n> That's because you can compose with ^ and ^, while you can't with @\n> and @. Does @{0}@{0} resolve?\n\n@{-1}@{0} does. That means @{0} is a revision and not a ref, but @{-1}\nis.\n\n'\"@\" given alone' has to be a ref if we want @@{5.minutes.ago} to\nresolve.\n"},{"id":"216035","messageId":"CALkWK0kcuaXTKbafmC72C3H+UZN6oeEY140T21LJUHveO=UBvA@mail.gmail.com","threadId":"33681","inReplyTo":"7vwqrjdh6v.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T18:22:28Z","receivedAt":"2013-04-30T18:22:28Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> @{-1}@{0} does. That means @{0} is a revision and not a ref, but @{-1}\n> is.\n\nRight. I missed that.\n\n> '\"@\" given alone' has to be a ref if we want @@{5.minutes.ago} to\n> resolve.\n\nYeah, I just realized that it's a bug in the @{u} implementation.\n@@{5.minutes.ago} and @@{1} work perfectly fine on git.git master.\nTherefore, @@{5.minutes.ago} should work with my implementation too.\nYes, it's just the default value of .git/@.\n"},{"id":"216036","messageId":"CALkWK0ndb-8dtVbUxTbwKTiC02_ut=0qX3p=KbvcpEqBi5jqcQ@mail.gmail.com","threadId":"33681","inReplyTo":"CALkWK0kcuaXTKbafmC72C3H+UZN6oeEY140T21LJUHveO=UBvA@mail.gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T18:24:03Z","receivedAt":"2013-04-30T18:24:03Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> @@{5.minutes.ago} and @@{1} work perfectly fine on git.git master.\n\n(with the .git/@ symref obviously)\n"},{"id":"216039","messageId":"CALkWK0n=Pkutg9cMXYV_+QmSXLROuU46wCEJfQkxEcNMFsOTgQ@mail.gmail.com","threadId":"33681","inReplyTo":"CALkWK0kcuaXTKbafmC72C3H+UZN6oeEY140T21LJUHveO=UBvA@mail.gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T18:40:26Z","receivedAt":"2013-04-30T18:40:26Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Therefore, @@{5.minutes.ago} should work with my implementation too.\n\nCaveat: we won't keep reflogs for @ unless the manual override .git/@\nis present (what's the point of keeping a duplicate of .git/logs/HEAD\nin .git/logs/@?). So, without the .git/@, @@{1} will complain that\nthe reflog only has 1 entry (in other words, it is \"correct\" but not\nuseful).\n"},{"id":"216042","messageId":"CALkWK0nBs0R3UJMN=JqcCFetQ4KCxE9XhqGp=83b7DiMdysfLw@mail.gmail.com","threadId":"33681","inReplyTo":"CALkWK0n=Pkutg9cMXYV_+QmSXLROuU46wCEJfQkxEcNMFsOTgQ@mail.gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-30T18:50:17Z","receivedAt":"2013-04-30T18:50:17Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> So, without the .git/@, @@{1} will complain that\n> the reflog only has 1 entry (in other words, it is \"correct\" but not\n> useful).\n\nEven better idea. When not overridden, @@{} will show the reflog\nfor HEAD. To the user, it looks like @ is behaving like a true ref by\nkeeping a reflog, but we're just cheating.\n"},{"id":"216073","messageId":"CAMP44s1LJg9kcBVMb8YxJDTEpKerJoN5td7276=JB7ZY6APpZw@mail.gmail.com","threadId":"33681","inReplyTo":"CALkWK0kcuaXTKbafmC72C3H+UZN6oeEY140T21LJUHveO=UBvA@mail.gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-30T22:00:34Z","receivedAt":"2013-04-30T22:00:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 30, 2013 at 1:22 PM, Ramkumar Ramachandra\n wrote:\n> Junio C Hamano wrote:\n>> @{-1}@{0} does. That means @{0} is a revision and not a ref, but @{-1}\n>> is.\n>\n> Right. I missed that.\n>\n>> '\"@\" given alone' has to be a ref if we want @@{5.minutes.ago} to\n>> resolve.\n>\n> Yeah, I just realized that it's a bug in the @{u} implementation.\n\nI don't think so. You probably need to modify branch_get(), because it\nhas a special case for \"HEAD\", and who knows if it's hard-coded in\nother places. It's not just the @{u} implementation.\n\nIf we do the magic at the rev-parsing phase, all these details become\nirrelevant.\n\nFTR. @@{upstream} and @@{now} works just fine in v2 of my patch series.\n\n-- \nFelipe Contreras\n"},{"id":"216118","messageId":"CACsJy8CZ8E-ASmo237rRbYR7pqoseo-NpU6jVrg6Rvd9qSY01w@mail.gmail.com","threadId":"33681","inReplyTo":"CALkWK0nnmzV0dcZ9avO9zDPhnQh9wkF7stA77cNycoXfecfUuw@mail.gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-01T02:18:41Z","receivedAt":"2013-05-01T02:18:41Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, May 1, 2013 at 12:15 AM, Ramkumar Ramachandra\n wrote:\n> Duy Nguyen wrote:\n>> We could put still ref aliases\n>> into the same ref namespace, with lower precedence that actual refs,\n>> so no new syntax required.\n>\n> Actually, ref-alises are the right way to solve the problem.\n> Recursive symref peeling is a bad idea: I can't take my aliases with\n> me, and they complicate unnecessarily.\n>\n> Any thoughts on how to implement it? Should it go as deep as\n> resolve_ref_unsafe()?\n\nDepends on how you define ref alias. resolve_ref_unsafe allows you to\nsubstitute one ref with another. Thomas was talking about substituting\npart of extended sha-1 syntax (U -> @{u}) so it can't be done down\nthere. I still think get_sha1_with_context_1() is the right place.\nStill not so sure how to handle when we have both alias \"U\" and\nrefs/heads/U.\n--\nDuy\n"},{"id":"216129","messageId":"87li7zcd3f.fsf@hexa.v.cablecom.net","threadId":"33681","inReplyTo":"CACsJy8CZ8E-ASmo237rRbYR7pqoseo-NpU6jVrg6Rvd9qSY01w@mail.gmail.com","subject":"Re: [PATCH] refs.c: interpret @ as HEAD","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-05-01T08:35:00Z","receivedAt":"2013-05-01T08:35:00Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Duy Nguyen writes:\n\n> On Wed, May 1, 2013 at 12:15 AM, Ramkumar Ramachandra\n> wrote:\n>> Duy Nguyen wrote:\n>>> We could put still ref aliases\n>>> into the same ref namespace, with lower precedence that actual refs,\n>>> so no new syntax required.\n>>\n>> Actually, ref-alises are the right way to solve the problem.\n>> Recursive symref peeling is a bad idea: I can't take my aliases with\n>> me, and they complicate unnecessarily.\n>>\n>> Any thoughts on how to implement it? Should it go as deep as\n>> resolve_ref_unsafe()?\n>\n> Depends on how you define ref alias. resolve_ref_unsafe allows you to\n> substitute one ref with another. Thomas was talking about substituting\n> part of extended sha-1 syntax (U -> @{u}) so it can't be done down\n> there. I still think get_sha1_with_context_1() is the right place.\n> Still not so sure how to handle when we have both alias \"U\" and\n> refs/heads/U.\n\nWell, I'm not sure about the semantics that I want. But so far I am\n*pretty* sure that I don't want it to be parameterized / part of another\nref.\n\nSo I'm fine with looking at *just* the alias, and resolving that to a\nSHA1, and going from there. So assuming U = @{u} and H = HEAD, you'd be\nallowed to say U^ or U..H but not HU or H@U or whatever contortionate\nsyntax that would need.\n\nAs for the collisions, not sure which one is better. Probably having\nthe same semantics as command aliases would be less confusing, i.e.,\nexisting refs take precedence.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"}]}