[PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Nicolas Pitre]

The work in progress to enable separate reflog for HEAD will make it
independent from reflog of any branch HEAD might be pointing to. In
the mean time disallow HEAD@{...} until that work is completed. Otherwise
people might get used to the current behavior which makes HEAD@{...} an
alias for <current_branch>@{...} which won't be the case later.

Signed-off-by: Nicolas Pitre <nico@cam.org>
---
 sha1_name.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index 9dfb3ac..70c6e42 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -301,12 +301,26 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 		fprintf(stderr, warning, len, str);
 
 	if (reflog_len) {
-		/* Is it asking for N-th entry, or approxidate? */
 		int nth, i;
 		unsigned long at_time;
 		unsigned long co_time;
 		int co_tz, co_cnt;
 
+		/*
+		 * We'll have an independent reflog for "HEAD" eventually
+		 * which won't be a synonym for the current branch reflog.
+		 * In the mean time prevent people from getting used to
+		 * such a synonym until the work is completed.
+		 */
+		if (!strncmp("HEAD", str, len) &&
+		    !strncmp(real_ref, "refs/", 5)) {
+			error("reflog for HEAD has not been implemented yet\n"
+			      "Maybe you could try %s%s instead.",
+			      strchr(real_ref+5, '/')+1, str + len);
+			exit(-1);
+		}
+
+		/* Is it asking for N-th entry, or approxidate? */
 		for (i = nth = 0; 0 <= nth && i < reflog_len; i++) {
 			char ch = str[at+2+i];
 			if ('0' <= ch && ch <= '9')
-- 
1.5.0.rc2.131.g4b01-dirty

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Shawn O. Pearce]

Nicolas Pitre <nico@cam.org> wrote:
> The work in progress to enable separate reflog for HEAD will make it
> independent from reflog of any branch HEAD might be pointing to. In
> the mean time disallow HEAD@{...} until that work is completed. Otherwise
> people might get used to the current behavior which makes HEAD@{...} an
> alias for <current_branch>@{...} which won't be the case later.

I happen to really like the fact that HEAD@{...} is an alias for
<current_branch>@{...}.

But now that HEAD will soon be getting its own reflog, I guess I
better relearn how to type <current_branch>.  :-)

-- 
Shawn.

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Nicolas Pitre <nico@cam.org> wrote:
>> The work in progress to enable separate reflog for HEAD will make it
>> independent from reflog of any branch HEAD might be pointing to. In
>> the mean time disallow HEAD@{...} until that work is completed. Otherwise
>> people might get used to the current behavior which makes HEAD@{...} an
>> alias for <current_branch>@{...} which won't be the case later.
>
> I happen to really like the fact that HEAD@{...} is an alias for
> <current_branch>@{...}.

It is usually easier to type.

> But now that HEAD will soon be getting its own reflog, I guess I
> better relearn how to type <current_branch>.  :-)

One thing that is certain is that master@{...} will mean the
same thing no matter what happens to Nico's series -- it talks
about where the tip of that particular branch was at any recent
time.  Right now HEAD@{...} happens to talk about "the current
branch" (and only the current branch) -- Nico's patch would
change the semantics when/if it is merged.

So I would not mind making sure that our documentation talks
only about specific branch's reflog for now (git grep 'HEAD@{'
in Documentation directory luckily hits nothing) but am a bit
reluctant to remove the already useful shorthand from a working
system.

Although from the consistency point of view, HEAD reflog to
follow swicthing branches like Nico's patch aims for (but not
implements fully yet) makes perfect sense, I still am somewhat
doubtful about it being actually useful in practice.  Even if we
assume it is useful, I think forbidding people from saying
HEAD@{...} right now only because the new semantics is
unimplemented yet feels wrong.  If you use only one branch,
there is no difference between the reflog of master and HEAD
today, without waiting for that "reflog on HEAD".

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Simon 'corecode' Schubert]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

Junio C Hamano wrote:
> Although from the consistency point of view, HEAD reflog to
> follow swicthing branches like Nico's patch aims for (but not
> implements fully yet) makes perfect sense, I still am somewhat
> doubtful about it being actually useful in practice.

I think that's quite useful.

>  Even if we
> assume it is useful, I think forbidding people from saying
> HEAD@{...} right now only because the new semantics is
> unimplemented yet feels wrong.  If you use only one branch,
> there is no difference between the reflog of master and HEAD
> today, without waiting for that "reflog on HEAD".

I don't know how people are used to type HEAD@{..}, but why not:

1.  have .@{..} or @@{..} for "the current branch i am on" and have HEAD@{..} behave like nicolas is aiming to do.

2. have HEAD@{..} to mean "the current branch i am on" and invent something else for "HEAD commit".  doesn't sound too logic, though.

ignore me if i'm sounding stupid :)

cheers
  simon

-- 
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Nicolas Pitre]

On Thu, 1 Feb 2007, Simon 'corecode' Schubert wrote:

> I don't know how people are used to type HEAD@{..}, but why not:
> 
> 1.  have .@{..} or @@{..} for "the current branch i am on" and have HEAD@{..}
> behave like nicolas is aiming to do.

I really like "@{...}" to mean whatever branch I'm on.  Given that it 
has no real name it can happily change meaning with branch switches.


Nicolas

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Matthias Lederhofer]

Nicolas Pitre <nico@cam.org> wrote:
> I really like "@{...}" to mean whatever branch I'm on.  Given that it 
> has no real name it can happily change meaning with branch switches.
Ack.

[PATCH 4/3] provide a nice @{...} syntax to always mean the current branch reflog

[Nicolas Pitre]

This is shorter than HEAD@{...} and being nameless it has no semantic 
issues.

Signed-off-by: Nicolas Pitre <nico@cam.org>
---

On Thu, 1 Feb 2007, Matthias Lederhofer wrote:

> Nicolas Pitre <nico@cam.org> wrote:
> > I really like "@{...}" to mean whatever branch I'm on.  Given that it 
> > has no real name it can happily change meaning with branch switches.
> Ack.

Here it is, on top of my previous patches.

diff --git a/sha1_name.c b/sha1_name.c
index 70c6e42..de8caf8 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -279,7 +279,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 	/* basic@{time or number} format to query ref-log */
 	reflog_len = at = 0;
 	if (str[len-1] == '}') {
-		for (at = 1; at < len - 1; at++) {
+		for (at = 0; at < len - 1; at++) {
 			if (str[at] == '@' && str[at+1] == '{') {
 				reflog_len = (len-1) - (at+2);
 				len = at;
@@ -289,10 +289,14 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 	}
 
 	/* Accept only unambiguous ref paths. */
-	if (ambiguous_path(str, len))
+	if (len && ambiguous_path(str, len))
 		return -1;
 
-	refs_found = dwim_ref(str, len, sha1, &real_ref);
+	if (!len && reflog_len) {
+		/* allow "@{...}" to mean the current branch reflog */
+		refs_found = dwim_ref("HEAD", 4, sha1, &real_ref);
+	} else
+		refs_found = dwim_ref(str, len, sha1, &real_ref);
 
 	if (!refs_found)
 		return -1;
@@ -312,11 +316,12 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
 		 * In the mean time prevent people from getting used to
 		 * such a synonym until the work is completed.
 		 */
-		if (!strncmp("HEAD", str, len) &&
+		if (len && !strncmp("HEAD", str, len) &&
 		    !strncmp(real_ref, "refs/", 5)) {
 			error("reflog for HEAD has not been implemented yet\n"
-			      "Maybe you could try %s%s instead.",
-			      strchr(real_ref+5, '/')+1, str + len);
+			      "Maybe you could try %s%s instead, "
+			      "or just %s for current branch..",
+			      strchr(real_ref+5, '/')+1, str+len, str+len);
 			exit(-1);
 		}
 

[PATCH 5/3], was Re: [PATCH 4/3] provide a nice @{...} syntax to always mean the current branch reflog

[Johannes Schindelin]

Also bring the '@{...}' notation to git-log -g

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

---

 reflog-walk.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/reflog-walk.c b/reflog-walk.c
index 8262160..653ec95 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -165,6 +165,14 @@ void add_reflog_for_walk(struct reflog_walk_info *info,
 	if (item)
 		reflogs = item->util;
 	else {
+		if (*branch == '\0') {
+			unsigned char sha1[20];
+			const char *head = resolve_ref("HEAD", sha1, 0, NULL);
+			if (!head)
+				die ("No current branch");
+			free(branch);
+			branch = xstrdup(head);
+		}
 		reflogs = read_complete_reflog(branch);
 		if (!reflogs || reflogs->nr == 0)
 			die("No reflogs found for '%s'", branch);

[PATCH 6/3], was Re: [PATCH 5/3], was Re: [PATCH 4/3] provide a nice @{...} syntax to always mean the current branch reflog

[Johannes Schindelin]

Update the documentation for the new '@{...}' syntax

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

---

 Documentation/git-rev-parse.txt |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index aeb37b6..4041a16 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -160,6 +160,10 @@ blobs contained in a commit.
   immediately following a ref name and the ref must have an existing
   log ($GIT_DIR/logs/<ref>).
 
+* You can use the '@' construct with an empty ref part to get at a
+  reflog of the current branch. For example, if you are on the
+  branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'.
+
 * A suffix '{caret}' to a revision parameter means the first parent of
   that commit object.  '{caret}<n>' means the <n>th parent (i.e.
   'rev{caret}'

Re: [PATCH 4/3] provide a nice @{...} syntax to always mean the current branch reflog

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> This is shorter than HEAD@{...} and being nameless it has no semantic 
> issues.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
> ---
>
> On Thu, 1 Feb 2007, Matthias Lederhofer wrote:
>
>> Nicolas Pitre <nico@cam.org> wrote:
>> > I really like "@{...}" to mean whatever branch I'm on.  Given that it 
>> > has no real name it can happily change meaning with branch switches.
>> Ack.
>
> Here it is, on top of my previous patches.

I think with this it makes a lot of sense to disallow HEAD@{}
until we are ready.

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Nicolas Pitre]

On Thu, 1 Feb 2007, Junio C Hamano wrote:

> Although from the consistency point of view, HEAD reflog to
> follow swicthing branches like Nico's patch aims for (but not
> implements fully yet) makes perfect sense, I still am somewhat
> doubtful about it being actually useful in practice.

It is useful as it then becomes almost impossible to lose things.  It 
could be a great tool to assist with user problems.  It also could serve 
as the data source for true back/undo/redo commands. And above all it 
just feels right.  ;-)

> Even if we assume it is useful, I think forbidding people from saying 
> HEAD@{...} right now only because the new semantics is unimplemented 
> yet feels wrong.  If you use only one branch, there is no difference 
> between the reflog of master and HEAD today, without waiting for that 
> "reflog on HEAD".

If you're OK with a potential semantic change for HEAD@{..} in the 
future then I don't mind.  The semantic change will affect those who 
actively use multiple branches and/or detached head.  Hopefully those 
people are confortable enough with git not to be confused by the change.

( I still think preventing HEAD@{} has its merits though )

Your call.


Nicolas

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Jakub Narebski]

Junio C Hamano wrote:

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
>> Nicolas Pitre <nico@cam.org> wrote:
>>> The work in progress to enable separate reflog for HEAD will make it
>>> independent from reflog of any branch HEAD might be pointing to. In
>>> the mean time disallow HEAD@{...} until that work is completed. Otherwise
>>> people might get used to the current behavior which makes HEAD@{...} an
>>> alias for <current_branch>@{...} which won't be the case later.
>>
>> I happen to really like the fact that HEAD@{...} is an alias for
>> <current_branch>@{...}.
> 
> It is usually easier to type.
> 
>> But now that HEAD will soon be getting its own reflog, I guess I
>> better relearn how to type <current_branch>.  :-)
> 
> One thing that is certain is that master@{...} will mean the
> same thing no matter what happens to Nico's series -- it talks
> about where the tip of that particular branch was at any recent
> time.  Right now HEAD@{...} happens to talk about "the current
> branch" (and only the current branch) -- Nico's patch would
> change the semantics when/if it is merged.

Perhaps we should use @{...} to refer to reflog for HEAD, or use
yet another special notation?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Johannes Schindelin]

Hi,

On Fri, 2 Feb 2007, Jakub Narebski wrote:

> Perhaps we should use @{...} to refer to reflog for HEAD, or use yet 
> another special notation?

No.

IMHO "bla@{yesterday}" should give you what "bla" pointed to, yesterday. 
In that sense, the proposed reflog on "HEAD" makes perfect sense.

I am not quite sure what I need most, the reflog for "HEAD", or that for 
my current branch. I guess it is the latter, so I am okay that 
"@{yesterday}" should mean the current branch, yesterday.

Ciao,
Dscho

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Lars Hjemli]

On 2/2/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 2 Feb 2007, Jakub Narebski wrote:
>
> > Perhaps we should use @{...} to refer to reflog for HEAD, or use yet
> > another special notation?
>
> No.
>
> IMHO "bla@{yesterday}" should give you what "bla" pointed to, yesterday.
> In that sense, the proposed reflog on "HEAD" makes perfect sense.

Since HEAD is a synonym for "current branch" everywhere else in git,
while .git/logs/HEAD will be a log of detached HEAD (plus branch
switches, I guess), I think the following makes perfect sense:

  "HEAD@{yesterday}" = current branch, yesterday
  "@{yesterday}"     = detached head (no branch), yesterday


Just my 2c

--
larsh

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Andy Parkins]

On Friday 2007 February 02 11:02, Lars Hjemli wrote:

>   "HEAD@{yesterday}" = current branch, yesterday
>   "@{yesterday}"     = detached head (no branch), yesterday

I'd vote for this too.  It's the only logically consistent view.

HEAD is a symbolic reference, it's a way of referring to a real branch by 
another name.  HEAD@{} should be the same as branch@{} to be consistent.

Forgetting about detached heads for the moment, imagine that yesterday I did 
lots of bouncing around on branches, around 1300 (although I wouldn't 
remember the exact time).  Oh look, it's about 1300 now.  What then is
HEAD@{yesterday} going to tell me?  What will it tell me one minute from now?  
It would be the most confusing operation in the world; I'd have to remember 
which branch I had checked out and what time I checked it out.

I really don't want to be able to answer the question what branch did I have 
checked out 15 minutes ago.  I do want to ask where was my current branch 15 
minutes ago.

Then of course, it's perfectly reasonable to treat the detached HEAD as 
meaning that the symref HEAD was pointing at a kind of virtual branch - this 
is a branch that isn't in the refs directory but is reflogged.  Other than 
that it's no different from any other branch.

Any notation would do I think, @{} is as good as any other.  In fact, if we 
used the name "unnamed branch" instead of "detached head", the notation @{} 
is perfect.  (Actually I think unnamed branch is a much better term than 
detached HEAD, because HEAD is never detached - it must point at something)



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Nicolas Pitre]

On Fri, 2 Feb 2007, Andy Parkins wrote:

> On Friday 2007 February 02 11:02, Lars Hjemli wrote:
> 
> >   "HEAD@{yesterday}" = current branch, yesterday
> >   "@{yesterday}"     = detached head (no branch), yesterday
> 
> I'd vote for this too.  It's the only logically consistent view.

No it is not.

> HEAD is a symbolic reference, it's a way of referring to a real branch by 
> another name.  HEAD@{} should be the same as branch@{} to be consistent.

HEAD is _NOT_ a symbolic reference.  It _may_ happen to be a symbolic 
reference, but it _may_ happen to not be.

And please see my previous email for more arguments.


Nicolas

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Nicolas Pitre]

On Fri, 2 Feb 2007, Andy Parkins wrote:

> Forgetting about detached heads for the moment,

That is not the way to go about it.  You cannot start forgetting about 
detached heads and come back to it afterwards like an afterthought.

> imagine that yesterday I did 
> lots of bouncing around on branches, around 1300 (although I wouldn't 
> remember the exact time).  Oh look, it's about 1300 now.  What then is
> HEAD@{yesterday} going to tell me?  What will it tell me one minute from now?  
> It would be the most confusing operation in the world; I'd have to remember 
> which branch I had checked out and what time I checked it out.

The exact same argument could be said if you did 1300 operations on a 
single branch, say master.  What would master@{yesterday} tell you?  
What will it tell you one minute from now?  Now suppose that you have 
only one branch and therefore HEAD reflog would be a duplicate of master 
reflog.

Answer: it would carry the same kind of confusion as your example above.

> I really don't want to be able to answer the question what branch did I have 
> checked out 15 minutes ago.  I do want to ask where was my current branch 15 
> minutes ago.

Then simply use @{15 minutes ago}.  You'll even save yourself some 
typing!  It is not like if you have to type HEAD for most operations 
anyway since HEAD is the likely default in most cases.  So you may even 
forget that the HEAD entity exists and be just fine.

But HEAD is still a moving pointer and we might want to know that it 
switched from one branch to another at some point.  And the only way for 
that to be sensible is by having a separate reflog for HEAD that is the 
exact log of every operations you perform regardless of the actual 
branch you might be on.

> Then of course, it's perfectly reasonable to treat the detached HEAD as 
> meaning that the symref HEAD was pointing at a kind of virtual branch - this 
> is a branch that isn't in the refs directory but is reflogged.  Other than 
> that it's no different from any other branch.
> 
> Any notation would do I think, @{} is as good as any other.  In fact, if we 
> used the name "unnamed branch" instead of "detached head", the notation @{} 
> is perfect.  (Actually I think unnamed branch is a much better term than 
> detached HEAD, because HEAD is never detached - it must point at something)

HEAD _does_ get detached.  It becomes loose in the air.  It doesn't drag 
any 
branch 
pointer with it.  And everything you do on top of a detached HEAD will 
be forgotten as soon as you leave it (and the eventual reflog for HEAD 
expires) if you don't attach it somehow with a tag or a new branch.  
There is no notion of a virtual branch at all, not technically, not 
conceptually either.


Nicolas

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Andy Parkins]

On Friday 2007 February 02 15:13, Nicolas Pitre wrote:
> On Fri, 2 Feb 2007, Andy Parkins wrote:
> > Forgetting about detached heads for the moment,
>
> That is not the way to go about it.  You cannot start forgetting about
> detached heads and come back to it afterwards like an afterthought.

I don't agree.  To avoid confusing people the key thing should be consistency.  
What holds true for HEAD in the non-detached case should hold true for the 
detached case.  Otherwise it's just another variable for the user to 
remember.

> The exact same argument could be said if you did 1300 operations on a
> single branch, say master.  What would master@{yesterday} tell you?
> What will it tell you one minute from now?  Now suppose that you have

It doesn't matter - it will be on the same head, as time ticks by I will at 
least find that master@{yesterday} ticks by linearly too.  That is not the 
case if HEAD@{yesterday} means "whatever HEAD pointed to yesterday".  How am 
I supposed to remember what it pointed to?  Therefore what use is 
HEAD@{yesterday}?

> only one branch and therefore HEAD reflog would be a duplicate of master
> reflog.

You misunderstand, I'm suggesting that reflogging HEAD is not the right thing 
to do.  Asking for HEAD's reflog should be the same as asking for the 
pointed-to-branch's reflog.

Instead, the reflog should be kept for the "unnamed branch", which would jump 
around each time you detached HEAD.

> Answer: it would carry the same kind of confusion as your example above.

I don't agree.  HEAD is always "the branch I'm on now", even when it's 
detached it's pointing at the branch I'm working on.  It just happens that 
that branch has no name.

> Then simply use @{15 minutes ago}.  You'll even save yourself some
> typing!  It is not like if you have to type HEAD for most operations

I'm not worried about the typing, or about the functionality.  I think that 
the functionality will be there in either of the proposed cases.  I am 
arguing which is the least confusing.  The amount of typing should certainly 
not be a factor in this case.

> anyway since HEAD is the likely default in most cases.  So you may even
> forget that the HEAD entity exists and be just fine.

Yep; in my scenario that's true.  One could completely forget about HEAD.  In 
your scenario that isn't the case, because I need to remember that when I'm 
detached HEAD suddenly gets special powers to tell me about the detached 
movements.

> But HEAD is still a moving pointer and we might want to know that it
> switched from one branch to another at some point.  And the only way for
> that to be sensible is by having a separate reflog for HEAD that is the
> exact log of every operations you perform regardless of the actual
> branch you might be on.

I agree.  I am arguing about nomenclature.  There is no dispute that /that/ 
reflog (or equivalent) should exist.  However, I don't believe it should 
be "the log of HEAD" it should be "the log of the unnamed branch".


> HEAD _does_ get detached.  It becomes loose in the air.  It doesn't drag

Well, we're talking semantics now.  HEAD becomes detached from a branch, but 
it certainly isn't floating.  It points at a particular point in the 
repository.

HEAD is always a symref (despite what you say); it's just that when HEAD is 
detached from all branches, there is no ref for it to point at, so we store 
the ref in the file called HEAD.  It's analogous to pointers in C:

  HashType hash;
  HashType *ref;
  HashType **HEAD;

By sometimes treating HEAD as a ref, you break the model.

> pointer with it.  And everything you do on top of a detached HEAD will
> be forgotten as soon as you leave it (and the eventual reflog for HEAD
> expires) if you don't attach it somehow with a tag or a new branch.
> There is no notion of a virtual branch at all, not technically, not
> conceptually either.

I disagree that there is no virtual branch.  That is what HEAD is when it is 
in detached mode.  It looks just like a ref - HEAD holds a hash, refs hold a 
hash - how is that not a virtual branch?  I used the word "virtual" only 
because it is not stored in refs/ and vanishes when you move back to a real 
branch.  Just because the virtual branch is stored in HEAD, I think it is 
dangerous to thing of HEAD as being the thing that is logged - it is this 
virtual branch that should be logged because that branch is always there and 
can be tracked through time as a discrete entity.  If you track HEAD itself, 
then sometimes it will hold the same as a branch reflog, sometimes it will 
hold unique data.

Perhaps this is just a product of my warped mental model of git.  Obviously 
you chaps who do the actual work get final say.  Take the above with my usual 
two cents of "I can't be sure of what I'm talking about" :-)




Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Simon 'corecode' Schubert]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

Andy Parkins wrote:
> Just because the virtual branch is stored in HEAD, I think it is 
> dangerous to thing of HEAD as being the thing that is logged - it is this 
> virtual branch that should be logged because that branch is always there and 
> can be tracked through time as a discrete entity.  If you track HEAD itself, 
> then sometimes it will hold the same as a branch reflog, sometimes it will 
> hold unique data.

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

So, to make it clear, when I do this:

git checkout master
git checkout build
git checkout master~1
git checkout dbcca21
git checkout master
hack && git commit -a

then i expect the "reflog to be named" to follow *exactly these steps:

master, build, master~1, dbcca21..., master, newmaster

and _not_ just

master~1m, dbcca21...

cheers
  simon

-- 
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Nicolas Pitre]

On Fri, 2 Feb 2007, Andy Parkins wrote:

> On Friday 2007 February 02 15:13, Nicolas Pitre wrote:
> > On Fri, 2 Feb 2007, Andy Parkins wrote:
> > > Forgetting about detached heads for the moment,
> >
> > That is not the way to go about it.  You cannot start forgetting about
> > detached heads and come back to it afterwards like an afterthought.
> 
> I don't agree.  To avoid confusing people the key thing should be 
> consistency.

I'm sorry but I can't help the fact that I think it's your argument that 
is inconsistent.

> What holds true for HEAD in the non-detached case should hold true for the 
> detached case.  Otherwise it's just another variable for the user to 
> remember.

I completely agree with that.

> > The exact same argument could be said if you did 1300 operations on a
> > single branch, say master.  What would master@{yesterday} tell you?
> > What will it tell you one minute from now?  Now suppose that you have
> 
> It doesn't matter - it will be on the same head, as time ticks by I will at 
> least find that master@{yesterday} ticks by linearly too.  That is not the 
> case if HEAD@{yesterday} means "whatever HEAD pointed to yesterday".  How am 
> I supposed to remember what it pointed to?  Therefore what use is 
> HEAD@{yesterday}?

It is there precisely to tell you what it pointed to yesterday, and how 
you happened to get there if you care.

If you want a particular branch reflog you just name it explicitly.

If you want the current branch's reflog you use @{...}.

Why would you use HEAD@{...} in that case?

> > only one branch and therefore HEAD reflog would be a duplicate of master
> > reflog.
> 
> You misunderstand, I'm suggesting that reflogging HEAD is not the right thing 
> to do. 

Then I understand that we won't agree on that point.

> Asking for HEAD's reflog should be the same as asking for the 
> pointed-to-branch's reflog.

That just has no logic.  HEAD is a pointer that can move inside 
branches, across branches, and even outside of any branches.  Remember 
that reflog is a "log", so the most obvious thing to do is simply that: 
logging operations affecting the HEAD pointer, _including_ the switching 
between branches, should be logged.

Having HEAD@{} named explicitly but changing meaning 
entirely depending on an implicit state (the current branch) when the 
explicit name doesn't change _is_ inconsistent in my book.  This is why 
there is now @{...} (no explicit name) that means the current branch 
reflog with no potential for confusion what so ever.

> Instead, the reflog should be kept for the "unnamed branch", which would jump 
> around each time you detached HEAD.
> 
> > Answer: it would carry the same kind of confusion as your example above.
> 
> I don't agree.  HEAD is always "the branch I'm on now", even when it's 
> detached it's pointing at the branch I'm working on. It just happens 
> that that branch has no name.

Whatever.  But you must admit that, with that same logic, the HEAD 
reflog should always be a log of "the branch you were on" at the time it 
has been recorded.

But because @{...} carries no name information, it has no _explicit_ 
meaning and therefore can refer to whatever reflog your current branch 
is at the moment.  It may change universe when you change branch just 
fine.

> > anyway since HEAD is the likely default in most cases.  So you may even
> > forget that the HEAD entity exists and be just fine.
> 
> Yep; in my scenario that's true.  One could completely forget about HEAD.  In 
> your scenario that isn't the case, because I need to remember that when I'm 
> detached HEAD suddenly gets special powers to tell me about the detached 
> movements.

No.  HEAD is never special.  HEAD@{} is a log of all values HEAD had in 
the past.  So HEAD@{5} will _always_ give you the fifth last position 
your checked out tree was at, regardless if it happened to be  on branch 
x or branch y or detached.  The same logic goes for master@{} which will 
_always_ return the previous values master might have had.

And because people want a shortcut to mean the reflog of the current 
branch then we use @{} without any explicit name.  This way the reflog 
for @{} being annonymous can change at will depending on the current 
branch without semantic confusion.

> > But HEAD is still a moving pointer and we might want to know that it
> > switched from one branch to another at some point.  And the only way for
> > that to be sensible is by having a separate reflog for HEAD that is the
> > exact log of every operations you perform regardless of the actual
> > branch you might be on.
> 
> I agree.  I am arguing about nomenclature.  There is no dispute that /that/ 
> reflog (or equivalent) should exist.  However, I don't believe it should 
> be "the log of HEAD" it should be "the log of the unnamed branch".

OK...  If what you want is an explicit "detached head" reflog then let's 
just create one!  But that doesn't eliminate the need for a separate 
HEAD reflog that includes all moves the HEAD pointer makes.

But IMHO I don't think the detached head should have a reflog of its 
own.  It is meant to be a volatile thing and since the HEAD reflog 
already contains moves made when HEAD is detached should be plenty 
enough for the detached head intended use.

> > HEAD _does_ get detached.  It becomes loose in the air.  It doesn't drag
> 
> Well, we're talking semantics now.  HEAD becomes detached from a branch, but 
> it certainly isn't floating.  It points at a particular point in the 
> repository.

So? Every ref always point to somewhere.  Don't be silly please.

> HEAD is always a symref (despite what you say); it's just that when HEAD is 
> detached from all branches, there is no ref for it to point at, so we store 
> the ref in the file called HEAD.

Please have a look at the git-symbolic-ref documentation.  When the ref 
is stored in the file called HEAD, then HEAD is _not_ a symbolic ref 
anymore.

> I disagree that there is no virtual branch.  That is what HEAD is when it is 
> in detached mode.  It looks just like a ref - HEAD holds a hash, refs hold a 
> hash - how is that not a virtual branch?  I used the word "virtual" only 
> because it is not stored in refs/ and vanishes when you move back to a real 
> branch.  Just because the virtual branch is stored in HEAD, I think it is 
> dangerous to thing of HEAD as being the thing that is logged - it is this 
> virtual branch that should be logged because that branch is always there and 
> can be tracked through time as a discrete entity.  If you track HEAD itself, 
> then sometimes it will hold the same as a branch reflog, sometimes it will 
> hold unique data.

Please consider the HEAD reflog as a _log_ of all operation the HEAD 
_pointer_ has seen.  Because that is all there is about it.  Forget that 
HEAD is a branch.  It is not a branch IT is a pointer.  "master" is a 
branch, "origin/next" is a (remote) branch.  But HEAD is not a branch it 
is a pointer.

OK branches are pointers too, but they are _branch_ pointer.  HEAD is 
_not_ a branch pointer.  It is only the current checked-out state 
pointer.  The HEAD pointer is a totally volatile thing.  Branch pointers 
are not volatile pointers.

This is why you should have a mental model for a detached head as the 
HEAD pointer being totally up in the air.  Sure it points to something, 
but it keeps its volatile nature.  When HEAD is not detached, it drags 
the current branch pointer along so the branch state is updated.  But 
that doesn't make HEAD more a branch pointer even though it might be 
pointing to a branch.


Nicolas

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Mark Wooding]

Andy Parkins <andyparkins@gmail.com> wrote:

> to do.  Asking for HEAD's reflog should be the same as asking for the 
> pointed-to-branch's reflog.

And what do you do when HEAD is detached?

I mean: I detach HEAD, and then ask about HEAD@{yesterday}.  It'd be
nonsensical for that to be an error, since HEAD surely did have a value
yesterday.  But it can't tell me where my current branch head was
yesterday, because there isn't a current branch to tell me about.

HEAD@{date} referring to the HEAD reflog is the only sane thing to do.

-- [mdw]

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Andy Parkins]

On Saturday 2007, February 03 17:07, Mark Wooding wrote:

> And what do you do when HEAD is detached?

Well; my proposal was that when head is detached HEAD@{} would return 
the "unnamed branch" reflog.

However, that idea has been rejected (which I'm fine with).

> I mean: I detach HEAD, and then ask about HEAD@{yesterday}.  It'd be
> nonsensical for that to be an error, since HEAD surely did have a
> value yesterday.  But it can't tell me where my current branch head
> was yesterday, because there isn't a current branch to tell me about.
>
> HEAD@{date} referring to the HEAD reflog is the only sane thing to
> do.

Well I don't think "only sane thing" is entirely accurate; I'm happy to 
accept counter arguments, but rhetoric doesn't count.

My (abandoned) suggestion was that

 HEAD@{..} on a undetached head would be equal to <current-branch>@{..}
 HEAD@{..} on a detached head would be equal to unnamed-branch@{..}
 @{..} would be equal to <whatever-i-was-on>@{...}

I accept (but not necessarily condone) that the counter proposal is also 
valid.  My argument is about which is the more consistent.  It would 
appear to be a judgment call; so I'm happy to bow out.  I don't think 
calling me insane (by proxy) lends any weight to any argument.



Andy

-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Jakub Narebski]

Lars Hjemli wrote:
> On 2/2/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Fri, 2 Feb 2007, Jakub Narebski wrote:
>>
>>> Perhaps we should use @{...} to refer to reflog for HEAD, or use yet
>>> another special notation?
>>
>> No.
>>
>> IMHO "bla@{yesterday}" should give you what "bla" pointed to, yesterday.
>> In that sense, the proposed reflog on "HEAD" makes perfect sense.
> 
> Since HEAD is a synonym for "current branch" everywhere else in git,
> while .git/logs/HEAD will be a log of detached HEAD (plus branch
> switches, I guess), I think the following makes perfect sense:
> 
>   "HEAD@{yesterday}" = current branch, yesterday
>   "@{yesterday}"     = detached head (no branch), yesterday

In the counterproposal, we have

   "HEAD@{yesterday}" = where HEAD was at, yesterday
   "@{yesterday}"     = current branch, yesterday

The side with patch wins (well, the one that can convince Junio).
But serously, that decision is work for maintainer.
-- 
Jakub Narebski
Poland

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Simon 'corecode' Schubert]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

Lars Hjemli wrote:
>  "HEAD@{yesterday}" = current branch, yesterday
>  "@{yesterday}"     = detached head (no branch), yesterday

+1 (actually not only "detached head", but "where my workdir was", including named branches as well)

-- 
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Simon 'corecode' Schubert]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Simon 'corecode' Schubert wrote:
> Lars Hjemli wrote:
>>  "HEAD@{yesterday}" = current branch, yesterday
>>  "@{yesterday}"     = detached head (no branch), yesterday
> 
> +1 (actually not only "detached head", but "where my workdir was", 
> including named branches as well)

okay, I take this back and claim the opposite:

+1 for

@{..} = current branch
HEAD@{..} = log of where HEAD was, detached or not detached, no matter

cheers
  simon

-- 
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Nicolas Pitre]

On Fri, 2 Feb 2007, Lars Hjemli wrote:

> On 2/2/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Fri, 2 Feb 2007, Jakub Narebski wrote:
> >
> > > Perhaps we should use @{...} to refer to reflog for HEAD, or use yet
> > > another special notation?
> >
> > No.
> >
> > IMHO "bla@{yesterday}" should give you what "bla" pointed to, yesterday.
> > In that sense, the proposed reflog on "HEAD" makes perfect sense.
> 
> Since HEAD is a synonym for "current branch" everywhere else in git,
> while .git/logs/HEAD will be a log of detached HEAD (plus branch
> switches, I guess), I think the following makes perfect sense:
> 
>  "HEAD@{yesterday}" = current branch, yesterday
>  "@{yesterday}"     = detached head (no branch), yesterday

No it doesn't.

HEAD is a moving pointer.  Sometimes it means the current branch, 
sometimes it doesn't.

So HEAD is _NOT_ a synonym for "current branch" everywhere already.

And it is really nice to reflog the switching between branch which makes 
sense only if HEAD has a reflog of its own.

If I want to know where HEAD was yesterday, then the only way to get to 
this info is with a separate reflog for HEAD.  IF HEAD was a synonym for 
the current branch then it is impossible to know where HEAD was 
yesterday because you only get the info about where the current branch 
was yesterday.  But it is all possible that the yesterday's current 
branch wasn't the same as today's current branch.


Nicolas

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Lars Hjemli]

On 2/2/07, Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 2 Feb 2007, Lars Hjemli wrote:
>
> > On 2/2/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Hi,
> > >
> > > On Fri, 2 Feb 2007, Jakub Narebski wrote:
> > >
> > > > Perhaps we should use @{...} to refer to reflog for HEAD, or use yet
> > > > another special notation?
> > >
> > > No.
> > >
> > > IMHO "bla@{yesterday}" should give you what "bla" pointed to, yesterday.
> > > In that sense, the proposed reflog on "HEAD" makes perfect sense.
> >
> > Since HEAD is a synonym for "current branch" everywhere else in git,
> > while .git/logs/HEAD will be a log of detached HEAD (plus branch
> > switches, I guess), I think the following makes perfect sense:
> >
> >  "HEAD@{yesterday}" = current branch, yesterday
> >  "@{yesterday}"     = detached head (no branch), yesterday
>
> No it doesn't.
>
> HEAD is a moving pointer.  Sometimes it means the current branch,
> sometimes it doesn't.
>
> So HEAD is _NOT_ a synonym for "current branch" everywhere already.

All true. I guess I'm just used to thinking about HEAD as a pointer to
the current branch, and that was the reasoning behind my proposal.

But with a detached HEAD this is no longer true, and you end up being right :)

Sorry for the noise

--
larsh

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Johannes Schindelin]

Hi,

On Fri, 2 Feb 2007, Lars Hjemli wrote:

> I think the following makes perfect sense:
> 
>  "HEAD@{yesterday}" = current branch, yesterday
>  "@{yesterday}"     = detached head (no branch), yesterday

Okay, so you say "HEAD@{yesterday}" does _not_ give you what HEAD pointed 
to yesterday, but "@{yesterday}" does?

Instead "HEAD@{yesterday}" looks up what HEAD points to _now_, and _then_ 
goes back to yesterday, finding out what that particular branch pointed to 
then, _regardless_ what HEAD was then?

Oh my, that's convoluted.

Ciao,
Dscho

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Fri, 2 Feb 2007, Lars Hjemli wrote:
> 
> > I think the following makes perfect sense:
> > 
> >  "HEAD@{yesterday}" = current branch, yesterday
> >  "@{yesterday}"     = detached head (no branch), yesterday
> 
> Okay, so you say "HEAD@{yesterday}" does _not_ give you what HEAD pointed 
> to yesterday, but "@{yesterday}" does?
> 
> Instead "HEAD@{yesterday}" looks up what HEAD points to _now_, and _then_ 
> goes back to yesterday, finding out what that particular branch pointed to 
> then, _regardless_ what HEAD was then?
> 
> Oh my, that's convoluted.

Depends on your point of view:

  HEAD: 1) noun.  Synonym for the branch I am currently on.
  HEAD: 2) noun.  Synonym for the commit I am currently on.

Now that we can detach our HEAD anytime we want, I'm in the
latter camp, and your (Dscho's) meaning for HEAD@{yesterday} and
@{yesterday} makes perfect sense.

But I suspect most Git users are still in the former camp, as they
haven't been exposed to the process (or need, or desire) to detach
their HEAD...

-- 
Shawn.

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Johannes Schindelin]

Hi,

On Mon, 5 Feb 2007, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Fri, 2 Feb 2007, Lars Hjemli wrote:
> > 
> > > I think the following makes perfect sense:
> > > 
> > >  "HEAD@{yesterday}" = current branch, yesterday
> > >  "@{yesterday}"     = detached head (no branch), yesterday
> > 
> > Okay, so you say "HEAD@{yesterday}" does _not_ give you what HEAD pointed 
> > to yesterday, but "@{yesterday}" does?
> > 
> > Instead "HEAD@{yesterday}" looks up what HEAD points to _now_, and _then_ 
> > goes back to yesterday, finding out what that particular branch pointed to 
> > then, _regardless_ what HEAD was then?
> > 
> > Oh my, that's convoluted.
> 
> Depends on your point of view:
> 
>   HEAD: 1) noun.  Synonym for the branch I am currently on.
>   HEAD: 2) noun.  Synonym for the commit I am currently on.

HEAD: 3) noun. The tip of the current branch.
HEAD: 4) noun. The part of the body I am right now banging on the wall.

> Now that we can detach our HEAD anytime we want, I'm in the latter camp, 
> and your (Dscho's) meaning for HEAD@{yesterday} and @{yesterday} makes 
> perfect sense.
> 
> But I suspect most Git users are still in the former camp, as they 
> haven't been exposed to the process (or need, or desire) to detach their 
> HEAD...

But has _nothing_ to do with a detachable HEAD.

Once people know what HEAD is, they do

	git show HEAD

to see what the tip of their current branch looks like. Now, read out 
aloud "HEAD@{12:00.pm.yesterday}". Yes, that's right. It says "HEAD at 
noon yesterday".

I mean, it's really easy to see what HEAD is good for. If your head 
automatically resolved HEAD to "the current branch, right now, even if I 
am talking about another time", I find it convoluted.

That's all.

Ciao,
Dscho

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Lars Hjemli]

On 2/5/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 2 Feb 2007, Lars Hjemli wrote:
>
> > I think the following makes perfect sense:
> >
> >  "HEAD@{yesterday}" = current branch, yesterday
> >  "@{yesterday}"     = detached head (no branch), yesterday
>
> Okay, so you say "HEAD@{yesterday}" does _not_ give you what HEAD pointed
> to yesterday, but "@{yesterday}" does?
>
> Instead "HEAD@{yesterday}" looks up what HEAD points to _now_, and _then_
> goes back to yesterday, finding out what that particular branch pointed to
> then, _regardless_ what HEAD was then?
>
> Oh my, that's convoluted.
>

Well, luckily Nicolas got me thinking straight again:

  http://article.gmane.org/gmane.comp.version-control.git/38507

-- 
larsh

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Andy Parkins]

On Thursday 2007 February 01 17:33, Nicolas Pitre wrote:

> The work in progress to enable separate reflog for HEAD will make it
> independent from reflog of any branch HEAD might be pointing to. In
> the mean time disallow HEAD@{...} until that work is completed. Otherwise
> people might get used to the current behavior which makes HEAD@{...} an
> alias for <current_branch>@{...} which won't be the case later.

I hadn't really appreciated the implications of all this HEAD reflog stuff 
until now.

Please, please, HEAD@{} should /always/ be an alias for <current_branch>@{}.

There is one special case:  when head is detached, <current_branch> would then 
be the "unnamed branch" for reflog purposes; personally I'd like that stored 
in .git/logs/DETACHED_HEAD or similar - in particular not in .git/logs/HEAD.



Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Rogan Dawes]

Andy Parkins wrote:
> On Thursday 2007 February 01 17:33, Nicolas Pitre wrote:
> 
>> The work in progress to enable separate reflog for HEAD will make it
>> independent from reflog of any branch HEAD might be pointing to. In
>> the mean time disallow HEAD@{...} until that work is completed. Otherwise
>> people might get used to the current behavior which makes HEAD@{...} an
>> alias for <current_branch>@{...} which won't be the case later.
> 
> I hadn't really appreciated the implications of all this HEAD reflog stuff 
> until now.
> 
> Please, please, HEAD@{} should /always/ be an alias for <current_branch>@{}.
> 
> There is one special case:  when head is detached, <current_branch> would then 
> be the "unnamed branch" for reflog purposes; personally I'd like that stored 
> in .git/logs/DETACHED_HEAD or similar - in particular not in .git/logs/HEAD.
> 
> Andy
> 

However, if HEAD@{} means what was HEAD pointing at at the indicated 
time, and @{} means "current branch", then we need no exceptions, and 
the common case is shorter.

Rogan

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Andy Parkins]

On Friday 2007 February 02 15:15, Rogan Dawes wrote:

> However, if HEAD@{} means what was HEAD pointing at at the indicated
> time, and @{} means "current branch", then we need no exceptions, and
> the common case is shorter.

In that case I propose that we rename git-commit to git-c; git checkout to 
git-o and git-merge to git-m.

Apologies.  I'm being facetious.  I don't think "which is the less typing" 
should be the decision policy when we're only talking about four letters.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> Please, please, HEAD@{} should /always/ be an alias for <current_branch>@{}.

I was confused, and after thinking about it a bit, I agree with
Nico's new @{} shorthand.

HEAD means "current" everywhere in git, but it does not
necessarily mean "current branch" (i.e. detached HEAD).  

But it almost always means the "current commit".  It is the
commit "git commit" builds on top of, and "git diff --cached"
and "git status" compare against.  It means the current branch
only in very limited contexts (exactly when we want a branch
name to operate on --- resetting and growing the branch tip via
commit/rebase/etc.).

Reflog is a vehicle to go back in time and time machines have
interesting interaction with the notion of "current".

HEAD@{5.minutes.ago} could mean "dereference HEAD symref to find
out what branch we are on RIGHT NOW, and then find out where the
tip of that branch was 5 minutes ago".  Alternatively it could
mean "what is the commit I would have referred to as HEAD 5
minutes ago, e.g. if I did "git show HEAD" back then".

I think both are useful, and the former semantics is given by
the "emptiness followed by @{} refers to the current branch"
shorthand, while yet-to-be-implemented HEAD@{} would give the
latter.

And I think the way Nico defined 'HEAD@{...}' is more consistent
with the way 'master@{...}' behaves; they both mean "what commit
did I mean if I said this at time ...".

I am not going to seriously suggest this, but it is conceivable
to want to be able to say things like "master^2~28@{yesterday}".
Naturally it would mean the 28th generation parent of the other
branch I merged into my 'master' branch yesterday (i.e. it asks
the question: "which commit would I have seen if I said "git
show master^2~28" yesterday?").