{"thread":{"id":"6609","subject":"[PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","startedAt":"2007-02-01T17:33:23Z","lastAt":"2007-02-05T23:11:26Z","messageCount":35,"participants":["Nicolas Pitre","Shawn O. Pearce","Junio C Hamano","Simon 'corecode' Schubert","Matthias Lederhofer","Johannes Schindelin","Jakub Narebski","Lars Hjemli","Andy Parkins","Rogan Dawes","Mark Wooding"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"33260","messageId":"Pine.LNX.4.64.0702011231300.3021@xanadu.home","threadId":"6609","inReplyTo":null,"subject":"[PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-01T17:33:23Z","receivedAt":"2007-02-01T17:33:23Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"The work in progress to enable separate reflog for HEAD will make it\nindependent from reflog of any branch HEAD might be pointing to. In\nthe mean time disallow HEAD@{...} until that work is completed. Otherwise\npeople might get used to the current behavior which makes HEAD@{...} an\nalias for <current_branch>@{...} which won't be the case later.\n\nSigned-off-by: Nicolas Pitre <nico@cam.org>\n---\n sha1_name.c |   16 +++++++++++++++-\n 1 files changed, 15 insertions(+), 1 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 9dfb3ac..70c6e42 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -301,12 +301,26 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n \t\tfprintf(stderr, warning, len, str);\n \n \tif (reflog_len) {\n-\t\t/* Is it asking for N-th entry, or approxidate? */\n \t\tint nth, i;\n \t\tunsigned long at_time;\n \t\tunsigned long co_time;\n \t\tint co_tz, co_cnt;\n \n+\t\t/*\n+\t\t * We'll have an independent reflog for \"HEAD\" eventually\n+\t\t * which won't be a synonym for the current branch reflog.\n+\t\t * In the mean time prevent people from getting used to\n+\t\t * such a synonym until the work is completed.\n+\t\t */\n+\t\tif (!strncmp(\"HEAD\", str, len) &&\n+\t\t    !strncmp(real_ref, \"refs/\", 5)) {\n+\t\t\terror(\"reflog for HEAD has not been implemented yet\\n\"\n+\t\t\t      \"Maybe you could try %s%s instead.\",\n+\t\t\t      strchr(real_ref+5, '/')+1, str + len);\n+\t\t\texit(-1);\n+\t\t}\n+\n+\t\t/* Is it asking for N-th entry, or approxidate? */\n \t\tfor (i = nth = 0; 0 <= nth && i < reflog_len; i++) {\n \t\t\tchar ch = str[at+2+i];\n \t\t\tif ('0' <= ch && ch <= '9')\n-- \n1.5.0.rc2.131.g4b01-dirty\n"},{"id":"33269","messageId":"20070201191323.GA18608@spearce.org","threadId":"6609","inReplyTo":"Pine.LNX.4.64.0702011231300.3021@xanadu.home","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-01T19:13:23Z","receivedAt":"2007-02-01T19:13:23Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre <nico@cam.org> wrote:\n> The work in progress to enable separate reflog for HEAD will make it\n> independent from reflog of any branch HEAD might be pointing to. In\n> the mean time disallow HEAD@{...} until that work is completed. Otherwise\n> people might get used to the current behavior which makes HEAD@{...} an\n> alias for <current_branch>@{...} which won't be the case later.\n\nI happen to really like the fact that HEAD@{...} is an alias for\n<current_branch>@{...}.\n\nBut now that HEAD will soon be getting its own reflog, I guess I\nbetter relearn how to type <current_branch>.  :-)\n\n-- \nShawn.\n"},{"id":"33282","messageId":"7vmz3xoas9.fsf@assigned-by-dhcp.cox.net","threadId":"6609","inReplyTo":"20070201191323.GA18608@spearce.org","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-01T20:58:14Z","receivedAt":"2007-02-01T20:58:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> Nicolas Pitre <nico@cam.org> wrote:\n>> The work in progress to enable separate reflog for HEAD will make it\n>> independent from reflog of any branch HEAD might be pointing to. In\n>> the mean time disallow HEAD@{...} until that work is completed. Otherwise\n>> people might get used to the current behavior which makes HEAD@{...} an\n>> alias for <current_branch>@{...} which won't be the case later.\n>\n> I happen to really like the fact that HEAD@{...} is an alias for\n> <current_branch>@{...}.\n\nIt is usually easier to type.\n\n> But now that HEAD will soon be getting its own reflog, I guess I\n> better relearn how to type <current_branch>.  :-)\n\nOne thing that is certain is that master@{...} will mean the\nsame thing no matter what happens to Nico's series -- it talks\nabout where the tip of that particular branch was at any recent\ntime.  Right now HEAD@{...} happens to talk about \"the current\nbranch\" (and only the current branch) -- Nico's patch would\nchange the semantics when/if it is merged.\n\nSo I would not mind making sure that our documentation talks\nonly about specific branch's reflog for now (git grep 'HEAD@{'\nin Documentation directory luckily hits nothing) but am a bit\nreluctant to remove the already useful shorthand from a working\nsystem.\n\nAlthough from the consistency point of view, HEAD reflog to\nfollow swicthing branches like Nico's patch aims for (but not\nimplements fully yet) makes perfect sense, I still am somewhat\ndoubtful about it being actually useful in practice.  Even if we\nassume it is useful, I think forbidding people from saying\nHEAD@{...} right now only because the new semantics is\nunimplemented yet feels wrong.  If you use only one branch,\nthere is no difference between the reflog of master and HEAD\ntoday, without waiting for that \"reflog on HEAD\".\n"},{"id":"33289","messageId":"45C25BA6.1000301@fs.ei.tum.de","threadId":"6609","inReplyTo":"7vmz3xoas9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-02-01T21:29:10Z","receivedAt":"2007-02-01T21:29:10Z","isPatch":true,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Although from the consistency point of view, HEAD reflog to\n> follow swicthing branches like Nico's patch aims for (but not\n> implements fully yet) makes perfect sense, I still am somewhat\n> doubtful about it being actually useful in practice.\n\nI think that's quite useful.\n\n>  Even if we\n> assume it is useful, I think forbidding people from saying\n> HEAD@{...} right now only because the new semantics is\n> unimplemented yet feels wrong.  If you use only one branch,\n> there is no difference between the reflog of master and HEAD\n> today, without waiting for that \"reflog on HEAD\".\n\nI don't know how people are used to type HEAD@{..}, but why not:\n\n1.  have .@{..} or @@{..} for \"the current branch i am on\" and have HEAD@{..} behave like nicolas is aiming to do.\n\n2. have HEAD@{..} to mean \"the current branch i am on\" and invent something else for \"HEAD commit\".  doesn't sound too logic, though.\n\nignore me if i'm sounding stupid :)\n\ncheers\n  simon\n\n-- \nServe - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /\"\\\nWork - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \\ /\nParty Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \\\nDude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \\\n\n"},{"id":"33291","messageId":"Pine.LNX.4.64.0702011632070.3021@xanadu.home","threadId":"6609","inReplyTo":"7vmz3xoas9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-01T21:46:56Z","receivedAt":"2007-02-01T21:46:56Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 1 Feb 2007, Junio C Hamano wrote:\n\n> Although from the consistency point of view, HEAD reflog to\n> follow swicthing branches like Nico's patch aims for (but not\n> implements fully yet) makes perfect sense, I still am somewhat\n> doubtful about it being actually useful in practice.\n\nIt is useful as it then becomes almost impossible to lose things.  It \ncould be a great tool to assist with user problems.  It also could serve \nas the data source for true back/undo/redo commands. And above all it \njust feels right.  ;-)\n\n> Even if we assume it is useful, I think forbidding people from saying \n> HEAD@{...} right now only because the new semantics is unimplemented \n> yet feels wrong.  If you use only one branch, there is no difference \n> between the reflog of master and HEAD today, without waiting for that \n> \"reflog on HEAD\".\n\nIf you're OK with a potential semantic change for HEAD@{..} in the \nfuture then I don't mind.  The semantic change will affect those who \nactively use multiple branches and/or detached head.  Hopefully those \npeople are confortable enough with git not to be confused by the change.\n\n( I still think preventing HEAD@{} has its merits though )\n\nYour call.\n\n\nNicolas\n"},{"id":"33296","messageId":"Pine.LNX.4.64.0702011710120.3021@xanadu.home","threadId":"6609","inReplyTo":"45C25BA6.1000301@fs.ei.tum.de","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-01T22:12:52Z","receivedAt":"2007-02-01T22:12:52Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 1 Feb 2007, Simon 'corecode' Schubert wrote:\n\n> I don't know how people are used to type HEAD@{..}, but why not:\n> \n> 1.  have .@{..} or @@{..} for \"the current branch i am on\" and have HEAD@{..}\n> behave like nicolas is aiming to do.\n\nI really like \"@{...}\" to mean whatever branch I'm on.  Given that it \nhas no real name it can happily change meaning with branch switches.\n\n\nNicolas\n"},{"id":"33299","messageId":"20070201221758.GA15213@moooo.ath.cx","threadId":"6609","inReplyTo":"Pine.LNX.4.64.0702011710120.3021@xanadu.home","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-02-01T22:17:58Z","receivedAt":"2007-02-01T22:17:58Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Nicolas Pitre <nico@cam.org> wrote:\n> I really like \"@{...}\" to mean whatever branch I'm on.  Given that it \n> has no real name it can happily change meaning with branch switches.\nAck.\n"},{"id":"33301","messageId":"Pine.LNX.4.64.0702011725150.3021@xanadu.home","threadId":"6609","inReplyTo":"20070201221758.GA15213@moooo.ath.cx","subject":"[PATCH 4/3] provide a nice @{...} syntax to always mean the current branch reflog","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-01T22:29:33Z","receivedAt":"2007-02-01T22:29:33Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"This is shorter than HEAD@{...} and being nameless it has no semantic \nissues.\n\nSigned-off-by: Nicolas Pitre <nico@cam.org>\n---\n\nOn Thu, 1 Feb 2007, Matthias Lederhofer wrote:\n\n> Nicolas Pitre <nico@cam.org> wrote:\n> > I really like \"@{...}\" to mean whatever branch I'm on.  Given that it \n> > has no real name it can happily change meaning with branch switches.\n> Ack.\n\nHere it is, on top of my previous patches.\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 70c6e42..de8caf8 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -279,7 +279,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n \t/* basic@{time or number} format to query ref-log */\n \treflog_len = at = 0;\n \tif (str[len-1] == '}') {\n-\t\tfor (at = 1; at < len - 1; at++) {\n+\t\tfor (at = 0; at < len - 1; at++) {\n \t\t\tif (str[at] == '@' && str[at+1] == '{') {\n \t\t\t\treflog_len = (len-1) - (at+2);\n \t\t\t\tlen = at;\n@@ -289,10 +289,14 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n \t}\n \n \t/* Accept only unambiguous ref paths. */\n-\tif (ambiguous_path(str, len))\n+\tif (len && ambiguous_path(str, len))\n \t\treturn -1;\n \n-\trefs_found = dwim_ref(str, len, sha1, &real_ref);\n+\tif (!len && reflog_len) {\n+\t\t/* allow \"@{...}\" to mean the current branch reflog */\n+\t\trefs_found = dwim_ref(\"HEAD\", 4, sha1, &real_ref);\n+\t} else\n+\t\trefs_found = dwim_ref(str, len, sha1, &real_ref);\n \n \tif (!refs_found)\n \t\treturn -1;\n@@ -312,11 +316,12 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n \t\t * In the mean time prevent people from getting used to\n \t\t * such a synonym until the work is completed.\n \t\t */\n-\t\tif (!strncmp(\"HEAD\", str, len) &&\n+\t\tif (len && !strncmp(\"HEAD\", str, len) &&\n \t\t    !strncmp(real_ref, \"refs/\", 5)) {\n \t\t\terror(\"reflog for HEAD has not been implemented yet\\n\"\n-\t\t\t      \"Maybe you could try %s%s instead.\",\n-\t\t\t      strchr(real_ref+5, '/')+1, str + len);\n+\t\t\t      \"Maybe you could try %s%s instead, \"\n+\t\t\t      \"or just %s for current branch..\",\n+\t\t\t      strchr(real_ref+5, '/')+1, str+len, str+len);\n \t\t\texit(-1);\n \t\t}\n \n"},{"id":"33305","messageId":"Pine.LNX.4.63.0702020006220.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6609","inReplyTo":"Pine.LNX.4.64.0702011725150.3021@xanadu.home","subject":"[PATCH 5/3], was Re: [PATCH 4/3] provide a nice @{...} syntax to always mean the current branch reflog","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-01T23:07:24Z","receivedAt":"2007-02-01T23:07:24Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Also bring the '@{...}' notation to git-log -g\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n\n---\n\n reflog-walk.c |    8 ++++++++\n 1 files changed, 8 insertions(+), 0 deletions(-)\n\ndiff --git a/reflog-walk.c b/reflog-walk.c\nindex 8262160..653ec95 100644\n--- a/reflog-walk.c\n+++ b/reflog-walk.c\n@@ -165,6 +165,14 @@ void add_reflog_for_walk(struct reflog_walk_info *info,\n \tif (item)\n \t\treflogs = item->util;\n \telse {\n+\t\tif (*branch == '\\0') {\n+\t\t\tunsigned char sha1[20];\n+\t\t\tconst char *head = resolve_ref(\"HEAD\", sha1, 0, NULL);\n+\t\t\tif (!head)\n+\t\t\t\tdie (\"No current branch\");\n+\t\t\tfree(branch);\n+\t\t\tbranch = xstrdup(head);\n+\t\t}\n \t\treflogs = read_complete_reflog(branch);\n \t\tif (!reflogs || reflogs->nr == 0)\n \t\t\tdie(\"No reflogs found for '%s'\", branch);\n"},{"id":"33307","messageId":"Pine.LNX.4.63.0702020021100.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6609","inReplyTo":"Pine.LNX.4.63.0702020006220.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"[PATCH 6/3], was Re: [PATCH 5/3], was Re: [PATCH 4/3] provide a nice @{...} syntax to always mean the current branch reflog","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-01T23:21:49Z","receivedAt":"2007-02-01T23:21:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Update the documentation for the new '@{...}' syntax\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n\n---\n\n Documentation/git-rev-parse.txt |    4 ++++\n 1 files changed, 4 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\nindex aeb37b6..4041a16 100644\n--- a/Documentation/git-rev-parse.txt\n+++ b/Documentation/git-rev-parse.txt\n@@ -160,6 +160,10 @@ blobs contained in a commit.\n   immediately following a ref name and the ref must have an existing\n   log ($GIT_DIR/logs/<ref>).\n \n+* You can use the '@' construct with an empty ref part to get at a\n+  reflog of the current branch. For example, if you are on the\n+  branch 'blabla', then '@\\{1\\}' means the same as 'blabla@\\{1\\}'.\n+\n * A suffix '{caret}' to a revision parameter means the first parent of\n   that commit object.  '{caret}<n>' means the <n>th parent (i.e.\n   'rev{caret}'\n"},{"id":"33323","messageId":"7v1wl9nyvv.fsf@assigned-by-dhcp.cox.net","threadId":"6609","inReplyTo":"Pine.LNX.4.64.0702011725150.3021@xanadu.home","subject":"Re: [PATCH 4/3] provide a nice @{...} syntax to always mean the current branch reflog","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-02T01:15:16Z","receivedAt":"2007-02-02T01:15:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre <nico@cam.org> writes:\n\n> This is shorter than HEAD@{...} and being nameless it has no semantic \n> issues.\n>\n> Signed-off-by: Nicolas Pitre <nico@cam.org>\n> ---\n>\n> On Thu, 1 Feb 2007, Matthias Lederhofer wrote:\n>\n>> Nicolas Pitre <nico@cam.org> wrote:\n>> > I really like \"@{...}\" to mean whatever branch I'm on.  Given that it \n>> > has no real name it can happily change meaning with branch switches.\n>> Ack.\n>\n> Here it is, on top of my previous patches.\n\nI think with this it makes a lot of sense to disallow HEAD@{}\nuntil we are ready.\n"},{"id":"33368","messageId":"epv3r9$4f7$2@sea.gmane.org","threadId":"6609","inReplyTo":"7vmz3xoas9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-02T10:31:23Z","receivedAt":"2007-02-02T10:31:23Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> \"Shawn O. Pearce\" <spearce@spearce.org> writes:\n> \n>> Nicolas Pitre <nico@cam.org> wrote:\n>>> The work in progress to enable separate reflog for HEAD will make it\n>>> independent from reflog of any branch HEAD might be pointing to. In\n>>> the mean time disallow HEAD@{...} until that work is completed. Otherwise\n>>> people might get used to the current behavior which makes HEAD@{...} an\n>>> alias for <current_branch>@{...} which won't be the case later.\n>>\n>> I happen to really like the fact that HEAD@{...} is an alias for\n>> <current_branch>@{...}.\n> \n> It is usually easier to type.\n> \n>> But now that HEAD will soon be getting its own reflog, I guess I\n>> better relearn how to type <current_branch>.  :-)\n> \n> One thing that is certain is that master@{...} will mean the\n> same thing no matter what happens to Nico's series -- it talks\n> about where the tip of that particular branch was at any recent\n> time.  Right now HEAD@{...} happens to talk about \"the current\n> branch\" (and only the current branch) -- Nico's patch would\n> change the semantics when/if it is merged.\n\nPerhaps we should use @{...} to refer to reflog for HEAD, or use\nyet another special notation?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33369","messageId":"Pine.LNX.4.63.0702021140340.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6609","inReplyTo":"epv3r9$4f7$2@sea.gmane.org","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-02T10:42:50Z","receivedAt":"2007-02-02T10:42:50Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 2 Feb 2007, Jakub Narebski wrote:\n\n> Perhaps we should use @{...} to refer to reflog for HEAD, or use yet \n> another special notation?\n\nNo.\n\nIMHO \"bla@{yesterday}\" should give you what \"bla\" pointed to, yesterday. \nIn that sense, the proposed reflog on \"HEAD\" makes perfect sense.\n\nI am not quite sure what I need most, the reflog for \"HEAD\", or that for \nmy current branch. I guess it is the latter, so I am okay that \n\"@{yesterday}\" should mean the current branch, yesterday.\n\nCiao,\nDscho\n"},{"id":"33372","messageId":"8c5c35580702020302g46f71fe3o24d7dc9490192cab@mail.gmail.com","threadId":"6609","inReplyTo":"Pine.LNX.4.63.0702021140340.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-02-02T11:02:24Z","receivedAt":"2007-02-02T11:02:24Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 2/2/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Fri, 2 Feb 2007, Jakub Narebski wrote:\n>\n> > Perhaps we should use @{...} to refer to reflog for HEAD, or use yet\n> > another special notation?\n>\n> No.\n>\n> IMHO \"bla@{yesterday}\" should give you what \"bla\" pointed to, yesterday.\n> In that sense, the proposed reflog on \"HEAD\" makes perfect sense.\n\nSince HEAD is a synonym for \"current branch\" everywhere else in git,\nwhile .git/logs/HEAD will be a log of detached HEAD (plus branch\nswitches, I guess), I think the following makes perfect sense:\n\n  \"HEAD@{yesterday}\" = current branch, yesterday\n  \"@{yesterday}\"     = detached head (no branch), yesterday\n\n\nJust my 2c\n\n--\nlarsh\n"},{"id":"33375","messageId":"200702021302.10567.andyparkins@gmail.com","threadId":"6609","inReplyTo":"8c5c35580702020302g46f71fe3o24d7dc9490192cab@mail.gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-02T13:02:07Z","receivedAt":"2007-02-02T13:02:07Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 February 02 11:02, Lars Hjemli wrote:\n\n>   \"HEAD@{yesterday}\" = current branch, yesterday\n>   \"@{yesterday}\"     = detached head (no branch), yesterday\n\nI'd vote for this too.  It's the only logically consistent view.\n\nHEAD is a symbolic reference, it's a way of referring to a real branch by \nanother name.  HEAD@{} should be the same as branch@{} to be consistent.\n\nForgetting about detached heads for the moment, imagine that yesterday I did \nlots of bouncing around on branches, around 1300 (although I wouldn't \nremember the exact time).  Oh look, it's about 1300 now.  What then is\nHEAD@{yesterday} going to tell me?  What will it tell me one minute from now?  \nIt would be the most confusing operation in the world; I'd have to remember \nwhich branch I had checked out and what time I checked it out.\n\nI really don't want to be able to answer the question what branch did I have \nchecked out 15 minutes ago.  I do want to ask where was my current branch 15 \nminutes ago.\n\nThen of course, it's perfectly reasonable to treat the detached HEAD as \nmeaning that the symref HEAD was pointing at a kind of virtual branch - this \nis a branch that isn't in the refs directory but is reflogged.  Other than \nthat it's no different from any other branch.\n\nAny notation would do I think, @{} is as good as any other.  In fact, if we \nused the name \"unnamed branch\" instead of \"detached head\", the notation @{} \nis perfect.  (Actually I think unnamed branch is a much better term than \ndetached HEAD, because HEAD is never detached - it must point at something)\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"33376","messageId":"200702021308.48599.andyparkins@gmail.com","threadId":"6609","inReplyTo":"Pine.LNX.4.64.0702011231300.3021@xanadu.home","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-02T13:08:46Z","receivedAt":"2007-02-02T13:08:46Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 February 01 17:33, Nicolas Pitre wrote:\n\n> The work in progress to enable separate reflog for HEAD will make it\n> independent from reflog of any branch HEAD might be pointing to. In\n> the mean time disallow HEAD@{...} until that work is completed. Otherwise\n> people might get used to the current behavior which makes HEAD@{...} an\n> alias for <current_branch>@{...} which won't be the case later.\n\nI hadn't really appreciated the implications of all this HEAD reflog stuff \nuntil now.\n\nPlease, please, HEAD@{} should /always/ be an alias for <current_branch>@{}.\n\nThere is one special case:  when head is detached, <current_branch> would then \nbe the \"unnamed branch\" for reflog purposes; personally I'd like that stored \nin .git/logs/DETACHED_HEAD or similar - in particular not in .git/logs/HEAD.\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"33378","messageId":"200702021421.22469.jnareb@gmail.com","threadId":"6609","inReplyTo":"8c5c35580702020302g46f71fe3o24d7dc9490192cab@mail.gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-02T13:21:21Z","receivedAt":"2007-02-02T13:21:21Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Lars Hjemli wrote:\n> On 2/2/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n>> On Fri, 2 Feb 2007, Jakub Narebski wrote:\n>>\n>>> Perhaps we should use @{...} to refer to reflog for HEAD, or use yet\n>>> another special notation?\n>>\n>> No.\n>>\n>> IMHO \"bla@{yesterday}\" should give you what \"bla\" pointed to, yesterday.\n>> In that sense, the proposed reflog on \"HEAD\" makes perfect sense.\n> \n> Since HEAD is a synonym for \"current branch\" everywhere else in git,\n> while .git/logs/HEAD will be a log of detached HEAD (plus branch\n> switches, I guess), I think the following makes perfect sense:\n> \n>   \"HEAD@{yesterday}\" = current branch, yesterday\n>   \"@{yesterday}\"     = detached head (no branch), yesterday\n\nIn the counterproposal, we have\n\n   \"HEAD@{yesterday}\" = where HEAD was at, yesterday\n   \"@{yesterday}\"     = current branch, yesterday\n\nThe side with patch wins (well, the one that can convince Junio).\nBut serously, that decision is work for maintainer.\n-- \nJakub Narebski\nPoland\n"},{"id":"33379","messageId":"45C3410A.4030407@fs.ei.tum.de","threadId":"6609","inReplyTo":"8c5c35580702020302g46f71fe3o24d7dc9490192cab@mail.gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-02-02T13:47:54Z","receivedAt":"2007-02-02T13:47:54Z","isPatch":true,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Lars Hjemli wrote:\n>  \"HEAD@{yesterday}\" = current branch, yesterday\n>  \"@{yesterday}\"     = detached head (no branch), yesterday\n\n+1 (actually not only \"detached head\", but \"where my workdir was\", including named branches as well)\n\n-- \nServe - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /\"\\\nWork - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \\ /\nParty Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \\\nDude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \\\n\n"},{"id":"33382","messageId":"Pine.LNX.4.64.0702020945090.3021@xanadu.home","threadId":"6609","inReplyTo":"8c5c35580702020302g46f71fe3o24d7dc9490192cab@mail.gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-02T14:52:48Z","receivedAt":"2007-02-02T14:52:48Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 2 Feb 2007, Lars Hjemli wrote:\n\n> On 2/2/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > Hi,\n> >\n> > On Fri, 2 Feb 2007, Jakub Narebski wrote:\n> >\n> > > Perhaps we should use @{...} to refer to reflog for HEAD, or use yet\n> > > another special notation?\n> >\n> > No.\n> >\n> > IMHO \"bla@{yesterday}\" should give you what \"bla\" pointed to, yesterday.\n> > In that sense, the proposed reflog on \"HEAD\" makes perfect sense.\n> \n> Since HEAD is a synonym for \"current branch\" everywhere else in git,\n> while .git/logs/HEAD will be a log of detached HEAD (plus branch\n> switches, I guess), I think the following makes perfect sense:\n> \n>  \"HEAD@{yesterday}\" = current branch, yesterday\n>  \"@{yesterday}\"     = detached head (no branch), yesterday\n\nNo it doesn't.\n\nHEAD is a moving pointer.  Sometimes it means the current branch, \nsometimes it doesn't.\n\nSo HEAD is _NOT_ a synonym for \"current branch\" everywhere already.\n\nAnd it is really nice to reflog the switching between branch which makes \nsense only if HEAD has a reflog of its own.\n\nIf I want to know where HEAD was yesterday, then the only way to get to \nthis info is with a separate reflog for HEAD.  IF HEAD was a synonym for \nthe current branch then it is impossible to know where HEAD was \nyesterday because you only get the info about where the current branch \nwas yesterday.  But it is all possible that the yesterday's current \nbranch wasn't the same as today's current branch.\n\n\nNicolas\n"},{"id":"33383","messageId":"Pine.LNX.4.64.0702020953190.3021@xanadu.home","threadId":"6609","inReplyTo":"200702021302.10567.andyparkins@gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-02T14:55:26Z","receivedAt":"2007-02-02T14:55:26Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 2 Feb 2007, Andy Parkins wrote:\n\n> On Friday 2007 February 02 11:02, Lars Hjemli wrote:\n> \n> >   \"HEAD@{yesterday}\" = current branch, yesterday\n> >   \"@{yesterday}\"     = detached head (no branch), yesterday\n> \n> I'd vote for this too.  It's the only logically consistent view.\n\nNo it is not.\n\n> HEAD is a symbolic reference, it's a way of referring to a real branch by \n> another name.  HEAD@{} should be the same as branch@{} to be consistent.\n\nHEAD is _NOT_ a symbolic reference.  It _may_ happen to be a symbolic \nreference, but it _may_ happen to not be.\n\nAnd please see my previous email for more arguments.\n\n\nNicolas\n"},{"id":"33385","messageId":"Pine.LNX.4.64.0702020955540.3021@xanadu.home","threadId":"6609","inReplyTo":"200702021302.10567.andyparkins@gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-02T15:13:11Z","receivedAt":"2007-02-02T15:13:11Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 2 Feb 2007, Andy Parkins wrote:\n\n> Forgetting about detached heads for the moment,\n\nThat is not the way to go about it.  You cannot start forgetting about \ndetached heads and come back to it afterwards like an afterthought.\n\n> imagine that yesterday I did \n> lots of bouncing around on branches, around 1300 (although I wouldn't \n> remember the exact time).  Oh look, it's about 1300 now.  What then is\n> HEAD@{yesterday} going to tell me?  What will it tell me one minute from now?  \n> It would be the most confusing operation in the world; I'd have to remember \n> which branch I had checked out and what time I checked it out.\n\nThe exact same argument could be said if you did 1300 operations on a \nsingle branch, say master.  What would master@{yesterday} tell you?  \nWhat will it tell you one minute from now?  Now suppose that you have \nonly one branch and therefore HEAD reflog would be a duplicate of master \nreflog.\n\nAnswer: it would carry the same kind of confusion as your example above.\n\n> I really don't want to be able to answer the question what branch did I have \n> checked out 15 minutes ago.  I do want to ask where was my current branch 15 \n> minutes ago.\n\nThen simply use @{15 minutes ago}.  You'll even save yourself some \ntyping!  It is not like if you have to type HEAD for most operations \nanyway since HEAD is the likely default in most cases.  So you may even \nforget that the HEAD entity exists and be just fine.\n\nBut HEAD is still a moving pointer and we might want to know that it \nswitched from one branch to another at some point.  And the only way for \nthat to be sensible is by having a separate reflog for HEAD that is the \nexact log of every operations you perform regardless of the actual \nbranch you might be on.\n\n> Then of course, it's perfectly reasonable to treat the detached HEAD as \n> meaning that the symref HEAD was pointing at a kind of virtual branch - this \n> is a branch that isn't in the refs directory but is reflogged.  Other than \n> that it's no different from any other branch.\n> \n> Any notation would do I think, @{} is as good as any other.  In fact, if we \n> used the name \"unnamed branch\" instead of \"detached head\", the notation @{} \n> is perfect.  (Actually I think unnamed branch is a much better term than \n> detached HEAD, because HEAD is never detached - it must point at something)\n\nHEAD _does_ get detached.  It becomes loose in the air.  It doesn't drag \nany \nbranch \npointer with it.  And everything you do on top of a detached HEAD will \nbe forgotten as soon as you leave it (and the eventual reflog for HEAD \nexpires) if you don't attach it somehow with a tag or a new branch.  \nThere is no notion of a virtual branch at all, not technically, not \nconceptually either.\n\n\nNicolas\n"},{"id":"33386","messageId":"45C3559B.80104@dawes.za.net","threadId":"6609","inReplyTo":"200702021308.48599.andyparkins@gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Rogan Dawes","fromEmail":"discard@dawes.za.net","sentAt":"2007-02-02T15:15:39Z","receivedAt":"2007-02-02T15:15:39Z","isPatch":true,"sender":{"key":"discard@dawes.za.net","avatar":null},"body":"Andy Parkins wrote:\n> On Thursday 2007 February 01 17:33, Nicolas Pitre wrote:\n> \n>> The work in progress to enable separate reflog for HEAD will make it\n>> independent from reflog of any branch HEAD might be pointing to. In\n>> the mean time disallow HEAD@{...} until that work is completed. Otherwise\n>> people might get used to the current behavior which makes HEAD@{...} an\n>> alias for <current_branch>@{...} which won't be the case later.\n> \n> I hadn't really appreciated the implications of all this HEAD reflog stuff \n> until now.\n> \n> Please, please, HEAD@{} should /always/ be an alias for <current_branch>@{}.\n> \n> There is one special case:  when head is detached, <current_branch> would then \n> be the \"unnamed branch\" for reflog purposes; personally I'd like that stored \n> in .git/logs/DETACHED_HEAD or similar - in particular not in .git/logs/HEAD.\n> \n> Andy\n> \n\nHowever, if HEAD@{} means what was HEAD pointing at at the indicated \ntime, and @{} means \"current branch\", then we need no exceptions, and \nthe common case is shorter.\n\nRogan\n"},{"id":"33388","messageId":"8c5c35580702020739v383c1efeu7851f5eb2a2ea5f@mail.gmail.com","threadId":"6609","inReplyTo":"Pine.LNX.4.64.0702020945090.3021@xanadu.home","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-02-02T15:39:22Z","receivedAt":"2007-02-02T15:39:22Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 2/2/07, Nicolas Pitre <nico@cam.org> wrote:\n> On Fri, 2 Feb 2007, Lars Hjemli wrote:\n>\n> > On 2/2/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > > Hi,\n> > >\n> > > On Fri, 2 Feb 2007, Jakub Narebski wrote:\n> > >\n> > > > Perhaps we should use @{...} to refer to reflog for HEAD, or use yet\n> > > > another special notation?\n> > >\n> > > No.\n> > >\n> > > IMHO \"bla@{yesterday}\" should give you what \"bla\" pointed to, yesterday.\n> > > In that sense, the proposed reflog on \"HEAD\" makes perfect sense.\n> >\n> > Since HEAD is a synonym for \"current branch\" everywhere else in git,\n> > while .git/logs/HEAD will be a log of detached HEAD (plus branch\n> > switches, I guess), I think the following makes perfect sense:\n> >\n> >  \"HEAD@{yesterday}\" = current branch, yesterday\n> >  \"@{yesterday}\"     = detached head (no branch), yesterday\n>\n> No it doesn't.\n>\n> HEAD is a moving pointer.  Sometimes it means the current branch,\n> sometimes it doesn't.\n>\n> So HEAD is _NOT_ a synonym for \"current branch\" everywhere already.\n\nAll true. I guess I'm just used to thinking about HEAD as a pointer to\nthe current branch, and that was the reasoning behind my proposal.\n\nBut with a detached HEAD this is no longer true, and you end up being right :)\n\nSorry for the noise\n\n--\nlarsh\n"},{"id":"33390","messageId":"200702021611.06029.andyparkins@gmail.com","threadId":"6609","inReplyTo":"Pine.LNX.4.64.0702020955540.3021@xanadu.home","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-02T16:11:03Z","receivedAt":"2007-02-02T16:11:03Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 February 02 15:13, Nicolas Pitre wrote:\n> On Fri, 2 Feb 2007, Andy Parkins wrote:\n> > Forgetting about detached heads for the moment,\n>\n> That is not the way to go about it.  You cannot start forgetting about\n> detached heads and come back to it afterwards like an afterthought.\n\nI don't agree.  To avoid confusing people the key thing should be consistency.  \nWhat holds true for HEAD in the non-detached case should hold true for the \ndetached case.  Otherwise it's just another variable for the user to \nremember.\n\n> The exact same argument could be said if you did 1300 operations on a\n> single branch, say master.  What would master@{yesterday} tell you?\n> What will it tell you one minute from now?  Now suppose that you have\n\nIt doesn't matter - it will be on the same head, as time ticks by I will at \nleast find that master@{yesterday} ticks by linearly too.  That is not the \ncase if HEAD@{yesterday} means \"whatever HEAD pointed to yesterday\".  How am \nI supposed to remember what it pointed to?  Therefore what use is \nHEAD@{yesterday}?\n\n> only one branch and therefore HEAD reflog would be a duplicate of master\n> reflog.\n\nYou misunderstand, I'm suggesting that reflogging HEAD is not the right thing \nto do.  Asking for HEAD's reflog should be the same as asking for the \npointed-to-branch's reflog.\n\nInstead, the reflog should be kept for the \"unnamed branch\", which would jump \naround each time you detached HEAD.\n\n> Answer: it would carry the same kind of confusion as your example above.\n\nI don't agree.  HEAD is always \"the branch I'm on now\", even when it's \ndetached it's pointing at the branch I'm working on.  It just happens that \nthat branch has no name.\n\n> Then simply use @{15 minutes ago}.  You'll even save yourself some\n> typing!  It is not like if you have to type HEAD for most operations\n\nI'm not worried about the typing, or about the functionality.  I think that \nthe functionality will be there in either of the proposed cases.  I am \narguing which is the least confusing.  The amount of typing should certainly \nnot be a factor in this case.\n\n> anyway since HEAD is the likely default in most cases.  So you may even\n> forget that the HEAD entity exists and be just fine.\n\nYep; in my scenario that's true.  One could completely forget about HEAD.  In \nyour scenario that isn't the case, because I need to remember that when I'm \ndetached HEAD suddenly gets special powers to tell me about the detached \nmovements.\n\n> But HEAD is still a moving pointer and we might want to know that it\n> switched from one branch to another at some point.  And the only way for\n> that to be sensible is by having a separate reflog for HEAD that is the\n> exact log of every operations you perform regardless of the actual\n> branch you might be on.\n\nI agree.  I am arguing about nomenclature.  There is no dispute that /that/ \nreflog (or equivalent) should exist.  However, I don't believe it should \nbe \"the log of HEAD\" it should be \"the log of the unnamed branch\".\n\n\n> HEAD _does_ get detached.  It becomes loose in the air.  It doesn't drag\n\nWell, we're talking semantics now.  HEAD becomes detached from a branch, but \nit certainly isn't floating.  It points at a particular point in the \nrepository.\n\nHEAD is always a symref (despite what you say); it's just that when HEAD is \ndetached from all branches, there is no ref for it to point at, so we store \nthe ref in the file called HEAD.  It's analogous to pointers in C:\n\n  HashType hash;\n  HashType *ref;\n  HashType **HEAD;\n\nBy sometimes treating HEAD as a ref, you break the model.\n\n> pointer with it.  And everything you do on top of a detached HEAD will\n> be forgotten as soon as you leave it (and the eventual reflog for HEAD\n> expires) if you don't attach it somehow with a tag or a new branch.\n> There is no notion of a virtual branch at all, not technically, not\n> conceptually either.\n\nI disagree that there is no virtual branch.  That is what HEAD is when it is \nin detached mode.  It looks just like a ref - HEAD holds a hash, refs hold a \nhash - how is that not a virtual branch?  I used the word \"virtual\" only \nbecause it is not stored in refs/ and vanishes when you move back to a real \nbranch.  Just because the virtual branch is stored in HEAD, I think it is \ndangerous to thing of HEAD as being the thing that is logged - it is this \nvirtual branch that should be logged because that branch is always there and \ncan be tracked through time as a discrete entity.  If you track HEAD itself, \nthen sometimes it will hold the same as a branch reflog, sometimes it will \nhold unique data.\n\nPerhaps this is just a product of my warped mental model of git.  Obviously \nyou chaps who do the actual work get final say.  Take the above with my usual \ntwo cents of \"I can't be sure of what I'm talking about\" :-)\n\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"33391","messageId":"200702021613.11058.andyparkins@gmail.com","threadId":"6609","inReplyTo":"45C3559B.80104@dawes.za.net","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-02T16:13:08Z","receivedAt":"2007-02-02T16:13:08Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 February 02 15:15, Rogan Dawes wrote:\n\n> However, if HEAD@{} means what was HEAD pointing at at the indicated\n> time, and @{} means \"current branch\", then we need no exceptions, and\n> the common case is shorter.\n\nIn that case I propose that we rename git-commit to git-c; git checkout to \ngit-o and git-merge to git-m.\n\nApologies.  I'm being facetious.  I don't think \"which is the less typing\" \nshould be the decision policy when we're only talking about four letters.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"33394","messageId":"45C3684E.7090402@fs.ei.tum.de","threadId":"6609","inReplyTo":"200702021611.06029.andyparkins@gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-02-02T16:35:26Z","receivedAt":"2007-02-02T16:35:26Z","isPatch":true,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Andy Parkins wrote:\n> Just because the virtual branch is stored in HEAD, I think it is \n> dangerous to thing of HEAD as being the thing that is logged - it is this \n> virtual branch that should be logged because that branch is always there and \n> can be tracked through time as a discrete entity.  If you track HEAD itself, \n> then sometimes it will hold the same as a branch reflog, sometimes it will \n> hold unique data.\n\nhopefully, yes!  Having to know \"uhm, that time I was detached, oh, no, that was a ref\" is the variable.  The reflog we are talking about, no matter how it might be called or how its symbol is should track where my index wanders.  which is called HEAD, I think (sorry, I'm quite new to git).\n\nSo, to make it clear, when I do this:\n\ngit checkout master\ngit checkout build\ngit checkout master~1\ngit checkout dbcca21\ngit checkout master\nhack && git commit -a\n\nthen i expect the \"reflog to be named\" to follow *exactly these steps:\n\nmaster, build, master~1, dbcca21..., master, newmaster\n\nand _not_ just\n\nmaster~1m, dbcca21...\n\ncheers\n  simon\n\n-- \nServe - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /\"\\\nWork - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \\ /\nParty Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \\\nDude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \\\n\n"},{"id":"33399","messageId":"Pine.LNX.4.64.0702021114480.3021@xanadu.home","threadId":"6609","inReplyTo":"200702021611.06029.andyparkins@gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-02T17:19:11Z","receivedAt":"2007-02-02T17:19:11Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 2 Feb 2007, Andy Parkins wrote:\n\n> On Friday 2007 February 02 15:13, Nicolas Pitre wrote:\n> > On Fri, 2 Feb 2007, Andy Parkins wrote:\n> > > Forgetting about detached heads for the moment,\n> >\n> > That is not the way to go about it.  You cannot start forgetting about\n> > detached heads and come back to it afterwards like an afterthought.\n> \n> I don't agree.  To avoid confusing people the key thing should be \n> consistency.\n\nI'm sorry but I can't help the fact that I think it's your argument that \nis inconsistent.\n\n> What holds true for HEAD in the non-detached case should hold true for the \n> detached case.  Otherwise it's just another variable for the user to \n> remember.\n\nI completely agree with that.\n\n> > The exact same argument could be said if you did 1300 operations on a\n> > single branch, say master.  What would master@{yesterday} tell you?\n> > What will it tell you one minute from now?  Now suppose that you have\n> \n> It doesn't matter - it will be on the same head, as time ticks by I will at \n> least find that master@{yesterday} ticks by linearly too.  That is not the \n> case if HEAD@{yesterday} means \"whatever HEAD pointed to yesterday\".  How am \n> I supposed to remember what it pointed to?  Therefore what use is \n> HEAD@{yesterday}?\n\nIt is there precisely to tell you what it pointed to yesterday, and how \nyou happened to get there if you care.\n\nIf you want a particular branch reflog you just name it explicitly.\n\nIf you want the current branch's reflog you use @{...}.\n\nWhy would you use HEAD@{...} in that case?\n\n> > only one branch and therefore HEAD reflog would be a duplicate of master\n> > reflog.\n> \n> You misunderstand, I'm suggesting that reflogging HEAD is not the right thing \n> to do. \n\nThen I understand that we won't agree on that point.\n\n> Asking for HEAD's reflog should be the same as asking for the \n> pointed-to-branch's reflog.\n\nThat just has no logic.  HEAD is a pointer that can move inside \nbranches, across branches, and even outside of any branches.  Remember \nthat reflog is a \"log\", so the most obvious thing to do is simply that: \nlogging operations affecting the HEAD pointer, _including_ the switching \nbetween branches, should be logged.\n\nHaving HEAD@{} named explicitly but changing meaning \nentirely depending on an implicit state (the current branch) when the \nexplicit name doesn't change _is_ inconsistent in my book.  This is why \nthere is now @{...} (no explicit name) that means the current branch \nreflog with no potential for confusion what so ever.\n\n> Instead, the reflog should be kept for the \"unnamed branch\", which would jump \n> around each time you detached HEAD.\n> \n> > Answer: it would carry the same kind of confusion as your example above.\n> \n> I don't agree.  HEAD is always \"the branch I'm on now\", even when it's \n> detached it's pointing at the branch I'm working on. It just happens \n> that that branch has no name.\n\nWhatever.  But you must admit that, with that same logic, the HEAD \nreflog should always be a log of \"the branch you were on\" at the time it \nhas been recorded.\n\nBut because @{...} carries no name information, it has no _explicit_ \nmeaning and therefore can refer to whatever reflog your current branch \nis at the moment.  It may change universe when you change branch just \nfine.\n\n> > anyway since HEAD is the likely default in most cases.  So you may even\n> > forget that the HEAD entity exists and be just fine.\n> \n> Yep; in my scenario that's true.  One could completely forget about HEAD.  In \n> your scenario that isn't the case, because I need to remember that when I'm \n> detached HEAD suddenly gets special powers to tell me about the detached \n> movements.\n\nNo.  HEAD is never special.  HEAD@{} is a log of all values HEAD had in \nthe past.  So HEAD@{5} will _always_ give you the fifth last position \nyour checked out tree was at, regardless if it happened to be  on branch \nx or branch y or detached.  The same logic goes for master@{} which will \n_always_ return the previous values master might have had.\n\nAnd because people want a shortcut to mean the reflog of the current \nbranch then we use @{} without any explicit name.  This way the reflog \nfor @{} being annonymous can change at will depending on the current \nbranch without semantic confusion.\n\n> > But HEAD is still a moving pointer and we might want to know that it\n> > switched from one branch to another at some point.  And the only way for\n> > that to be sensible is by having a separate reflog for HEAD that is the\n> > exact log of every operations you perform regardless of the actual\n> > branch you might be on.\n> \n> I agree.  I am arguing about nomenclature.  There is no dispute that /that/ \n> reflog (or equivalent) should exist.  However, I don't believe it should \n> be \"the log of HEAD\" it should be \"the log of the unnamed branch\".\n\nOK...  If what you want is an explicit \"detached head\" reflog then let's \njust create one!  But that doesn't eliminate the need for a separate \nHEAD reflog that includes all moves the HEAD pointer makes.\n\nBut IMHO I don't think the detached head should have a reflog of its \nown.  It is meant to be a volatile thing and since the HEAD reflog \nalready contains moves made when HEAD is detached should be plenty \nenough for the detached head intended use.\n\n> > HEAD _does_ get detached.  It becomes loose in the air.  It doesn't drag\n> \n> Well, we're talking semantics now.  HEAD becomes detached from a branch, but \n> it certainly isn't floating.  It points at a particular point in the \n> repository.\n\nSo? Every ref always point to somewhere.  Don't be silly please.\n\n> HEAD is always a symref (despite what you say); it's just that when HEAD is \n> detached from all branches, there is no ref for it to point at, so we store \n> the ref in the file called HEAD.\n\nPlease have a look at the git-symbolic-ref documentation.  When the ref \nis stored in the file called HEAD, then HEAD is _not_ a symbolic ref \nanymore.\n\n> I disagree that there is no virtual branch.  That is what HEAD is when it is \n> in detached mode.  It looks just like a ref - HEAD holds a hash, refs hold a \n> hash - how is that not a virtual branch?  I used the word \"virtual\" only \n> because it is not stored in refs/ and vanishes when you move back to a real \n> branch.  Just because the virtual branch is stored in HEAD, I think it is \n> dangerous to thing of HEAD as being the thing that is logged - it is this \n> virtual branch that should be logged because that branch is always there and \n> can be tracked through time as a discrete entity.  If you track HEAD itself, \n> then sometimes it will hold the same as a branch reflog, sometimes it will \n> hold unique data.\n\nPlease consider the HEAD reflog as a _log_ of all operation the HEAD \n_pointer_ has seen.  Because that is all there is about it.  Forget that \nHEAD is a branch.  It is not a branch IT is a pointer.  \"master\" is a \nbranch, \"origin/next\" is a (remote) branch.  But HEAD is not a branch it \nis a pointer.\n\nOK branches are pointers too, but they are _branch_ pointer.  HEAD is \n_not_ a branch pointer.  It is only the current checked-out state \npointer.  The HEAD pointer is a totally volatile thing.  Branch pointers \nare not volatile pointers.\n\nThis is why you should have a mental model for a detached head as the \nHEAD pointer being totally up in the air.  Sure it points to something, \nbut it keeps its volatile nature.  When HEAD is not detached, it drags \nthe current branch pointer along so the branch state is updated.  But \nthat doesn't make HEAD more a branch pointer even though it might be \npointing to a branch.\n\n\nNicolas\n"},{"id":"33410","messageId":"45C39392.9070000@fs.ei.tum.de","threadId":"6609","inReplyTo":"45C3410A.4030407@fs.ei.tum.de","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-02-02T19:40:02Z","receivedAt":"2007-02-02T19:40:02Z","isPatch":true,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Simon 'corecode' Schubert wrote:\n> Lars Hjemli wrote:\n>>  \"HEAD@{yesterday}\" = current branch, yesterday\n>>  \"@{yesterday}\"     = detached head (no branch), yesterday\n> \n> +1 (actually not only \"detached head\", but \"where my workdir was\", \n> including named branches as well)\n\nokay, I take this back and claim the opposite:\n\n+1 for\n\n@{..} = current branch\nHEAD@{..} = log of where HEAD was, detached or not detached, no matter\n\ncheers\n  simon\n\n-- \nServe - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /\"\\\nWork - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \\ /\nParty Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \\\nDude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \\\n\n"},{"id":"33429","messageId":"7v4pq4djre.fsf@assigned-by-dhcp.cox.net","threadId":"6609","inReplyTo":"200702021308.48599.andyparkins@gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-03T03:04:21Z","receivedAt":"2007-02-03T03:04:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> Please, please, HEAD@{} should /always/ be an alias for <current_branch>@{}.\n\nI was confused, and after thinking about it a bit, I agree with\nNico's new @{} shorthand.\n\nHEAD means \"current\" everywhere in git, but it does not\nnecessarily mean \"current branch\" (i.e. detached HEAD).  \n\nBut it almost always means the \"current commit\".  It is the\ncommit \"git commit\" builds on top of, and \"git diff --cached\"\nand \"git status\" compare against.  It means the current branch\nonly in very limited contexts (exactly when we want a branch\nname to operate on --- resetting and growing the branch tip via\ncommit/rebase/etc.).\n\nReflog is a vehicle to go back in time and time machines have\ninteresting interaction with the notion of \"current\".\n\nHEAD@{5.minutes.ago} could mean \"dereference HEAD symref to find\nout what branch we are on RIGHT NOW, and then find out where the\ntip of that branch was 5 minutes ago\".  Alternatively it could\nmean \"what is the commit I would have referred to as HEAD 5\nminutes ago, e.g. if I did \"git show HEAD\" back then\".\n\nI think both are useful, and the former semantics is given by\nthe \"emptiness followed by @{} refers to the current branch\"\nshorthand, while yet-to-be-implemented HEAD@{} would give the\nlatter.\n\nAnd I think the way Nico defined 'HEAD@{...}' is more consistent\nwith the way 'master@{...}' behaves; they both mean \"what commit\ndid I mean if I said this at time ...\".\n\nI am not going to seriously suggest this, but it is conceivable\nto want to be able to say things like \"master^2~28@{yesterday}\".\nNaturally it would mean the 28th generation parent of the other\nbranch I merged into my 'master' branch yesterday (i.e. it asks\nthe question: \"which commit would I have seen if I said \"git\nshow master^2~28\" yesterday?\").\n"},{"id":"33458","messageId":"slrnes9ga2.3l6.mdw@metalzone.distorted.org.uk","threadId":"6609","inReplyTo":"200702021611.06029.andyparkins@gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2007-02-03T17:07:14Z","receivedAt":"2007-02-03T17:07:14Z","isPatch":true,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"Andy Parkins <andyparkins@gmail.com> wrote:\n\n> to do.  Asking for HEAD's reflog should be the same as asking for the \n> pointed-to-branch's reflog.\n\nAnd what do you do when HEAD is detached?\n\nI mean: I detach HEAD, and then ask about HEAD@{yesterday}.  It'd be\nnonsensical for that to be an error, since HEAD surely did have a value\nyesterday.  But it can't tell me where my current branch head was\nyesterday, because there isn't a current branch to tell me about.\n\nHEAD@{date} referring to the HEAD reflog is the only sane thing to do.\n\n-- [mdw]\n"},{"id":"33461","messageId":"200702031754.19494.andyparkins@gmail.com","threadId":"6609","inReplyTo":"slrnes9ga2.3l6.mdw@metalzone.distorted.org.uk","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-03T17:54:17Z","receivedAt":"2007-02-03T17:54:17Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2007, February 03 17:07, Mark Wooding wrote:\n\n> And what do you do when HEAD is detached?\n\nWell; my proposal was that when head is detached HEAD@{} would return \nthe \"unnamed branch\" reflog.\n\nHowever, that idea has been rejected (which I'm fine with).\n\n> I mean: I detach HEAD, and then ask about HEAD@{yesterday}.  It'd be\n> nonsensical for that to be an error, since HEAD surely did have a\n> value yesterday.  But it can't tell me where my current branch head\n> was yesterday, because there isn't a current branch to tell me about.\n>\n> HEAD@{date} referring to the HEAD reflog is the only sane thing to\n> do.\n\nWell I don't think \"only sane thing\" is entirely accurate; I'm happy to \naccept counter arguments, but rhetoric doesn't count.\n\nMy (abandoned) suggestion was that\n\n HEAD@{..} on a undetached head would be equal to <current-branch>@{..}\n HEAD@{..} on a detached head would be equal to unnamed-branch@{..}\n @{..} would be equal to <whatever-i-was-on>@{...}\n\nI accept (but not necessarily condone) that the counter proposal is also \nvalid.  My argument is about which is the more consistent.  It would \nappear to be a judgment call; so I'm happy to bow out.  I don't think \ncalling me insane (by proxy) lends any weight to any argument.\n\n\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"},{"id":"33621","messageId":"Pine.LNX.4.63.0702051208070.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6609","inReplyTo":"8c5c35580702020302g46f71fe3o24d7dc9490192cab@mail.gmail.com","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-05T11:11:01Z","receivedAt":"2007-02-05T11:11:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 2 Feb 2007, Lars Hjemli wrote:\n\n> I think the following makes perfect sense:\n> \n>  \"HEAD@{yesterday}\" = current branch, yesterday\n>  \"@{yesterday}\"     = detached head (no branch), yesterday\n\nOkay, so you say \"HEAD@{yesterday}\" does _not_ give you what HEAD pointed \nto yesterday, but \"@{yesterday}\" does?\n\nInstead \"HEAD@{yesterday}\" looks up what HEAD points to _now_, and _then_ \ngoes back to yesterday, finding out what that particular branch pointed to \nthen, _regardless_ what HEAD was then?\n\nOh my, that's convoluted.\n\nCiao,\nDscho\n"},{"id":"33622","messageId":"20070205112101.GC14234@spearce.org","threadId":"6609","inReplyTo":"Pine.LNX.4.63.0702051208070.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-05T11:21:01Z","receivedAt":"2007-02-05T11:21:01Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> On Fri, 2 Feb 2007, Lars Hjemli wrote:\n> \n> > I think the following makes perfect sense:\n> > \n> >  \"HEAD@{yesterday}\" = current branch, yesterday\n> >  \"@{yesterday}\"     = detached head (no branch), yesterday\n> \n> Okay, so you say \"HEAD@{yesterday}\" does _not_ give you what HEAD pointed \n> to yesterday, but \"@{yesterday}\" does?\n> \n> Instead \"HEAD@{yesterday}\" looks up what HEAD points to _now_, and _then_ \n> goes back to yesterday, finding out what that particular branch pointed to \n> then, _regardless_ what HEAD was then?\n> \n> Oh my, that's convoluted.\n\nDepends on your point of view:\n\n  HEAD: 1) noun.  Synonym for the branch I am currently on.\n  HEAD: 2) noun.  Synonym for the commit I am currently on.\n\nNow that we can detach our HEAD anytime we want, I'm in the\nlatter camp, and your (Dscho's) meaning for HEAD@{yesterday} and\n@{yesterday} makes perfect sense.\n\nBut I suspect most Git users are still in the former camp, as they\nhaven't been exposed to the process (or need, or desire) to detach\ntheir HEAD...\n\n-- \nShawn.\n"},{"id":"33630","messageId":"Pine.LNX.4.63.0702051338261.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6609","inReplyTo":"20070205112101.GC14234@spearce.org","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-05T12:43:12Z","receivedAt":"2007-02-05T12:43:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Feb 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > On Fri, 2 Feb 2007, Lars Hjemli wrote:\n> > \n> > > I think the following makes perfect sense:\n> > > \n> > >  \"HEAD@{yesterday}\" = current branch, yesterday\n> > >  \"@{yesterday}\"     = detached head (no branch), yesterday\n> > \n> > Okay, so you say \"HEAD@{yesterday}\" does _not_ give you what HEAD pointed \n> > to yesterday, but \"@{yesterday}\" does?\n> > \n> > Instead \"HEAD@{yesterday}\" looks up what HEAD points to _now_, and _then_ \n> > goes back to yesterday, finding out what that particular branch pointed to \n> > then, _regardless_ what HEAD was then?\n> > \n> > Oh my, that's convoluted.\n> \n> Depends on your point of view:\n> \n>   HEAD: 1) noun.  Synonym for the branch I am currently on.\n>   HEAD: 2) noun.  Synonym for the commit I am currently on.\n\nHEAD: 3) noun. The tip of the current branch.\nHEAD: 4) noun. The part of the body I am right now banging on the wall.\n\n> Now that we can detach our HEAD anytime we want, I'm in the latter camp, \n> and your (Dscho's) meaning for HEAD@{yesterday} and @{yesterday} makes \n> perfect sense.\n> \n> But I suspect most Git users are still in the former camp, as they \n> haven't been exposed to the process (or need, or desire) to detach their \n> HEAD...\n\nBut has _nothing_ to do with a detachable HEAD.\n\nOnce people know what HEAD is, they do\n\n\tgit show HEAD\n\nto see what the tip of their current branch looks like. Now, read out \naloud \"HEAD@{12:00.pm.yesterday}\". Yes, that's right. It says \"HEAD at \nnoon yesterday\".\n\nI mean, it's really easy to see what HEAD is good for. If your head \nautomatically resolved HEAD to \"the current branch, right now, even if I \nam talking about another time\", I find it convoluted.\n\nThat's all.\n\nCiao,\nDscho\n"},{"id":"33679","messageId":"8c5c35580702051511m6d31973bw1f19832afe583487@mail.gmail.com","threadId":"6609","inReplyTo":"Pine.LNX.4.63.0702051208070.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-02-05T23:11:26Z","receivedAt":"2007-02-05T23:11:26Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 2/5/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Fri, 2 Feb 2007, Lars Hjemli wrote:\n>\n> > I think the following makes perfect sense:\n> >\n> >  \"HEAD@{yesterday}\" = current branch, yesterday\n> >  \"@{yesterday}\"     = detached head (no branch), yesterday\n>\n> Okay, so you say \"HEAD@{yesterday}\" does _not_ give you what HEAD pointed\n> to yesterday, but \"@{yesterday}\" does?\n>\n> Instead \"HEAD@{yesterday}\" looks up what HEAD points to _now_, and _then_\n> goes back to yesterday, finding out what that particular branch pointed to\n> then, _regardless_ what HEAD was then?\n>\n> Oh my, that's convoluted.\n>\n\nWell, luckily Nicolas got me thinking straight again:\n\n  http://article.gmane.org/gmane.comp.version-control.git/38507\n\n-- \nlarsh\n"}]}