From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:52
"Shawn O. Pearce" [off-list ref] writes:
Nicolas Pitre [off-list ref] wrote:
quoted
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".
From: Simon 'corecode' Schubert <hidden> Date: 2016-06-15 22:42:52
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 / \
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:42:52
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
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:42:52
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
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:42:52
This is shorter than HEAD@{...} and being nameless it has no semantic
issues.
Signed-off-by: Nicolas Pitre <redacted>
---
On Thu, 1 Feb 2007, Matthias Lederhofer wrote:
Nicolas Pitre [off-list ref] wrote:
quoted
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.
@@ -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)*Inthemeantimepreventpeoplefromgettingusedto*suchasynonymuntiltheworkiscompleted.*/-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);}
@@ -165,6 +165,14 @@ void add_reflog_for_walk(struct reflog_walk_info *info,if(item)reflogs=item->util;else{+if(*branch=='\0'){+unsignedcharsha1[20];+constchar*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);
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:52
Update the documentation for the new '@{...}' syntax
Signed-off-by: Johannes Schindelin <redacted>
---
Documentation/git-rev-parse.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
@@ -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}'
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:52
Junio C Hamano wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
Nicolas Pitre [off-list ref] wrote:
quoted
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.
quoted
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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:52
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
From: Lars Hjemli <hidden> Date: 2016-06-15 22:42:52
On 2/2/07, Johannes Schindelin [off-list ref] wrote:
Hi,
On Fri, 2 Feb 2007, Jakub Narebski wrote:
quoted
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
From: Andy Parkins <hidden> Date: 2016-06-15 22:42:52
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:52
Lars Hjemli wrote:
On 2/2/07, Johannes Schindelin [off-list ref] wrote:
quoted
On Fri, 2 Feb 2007, Jakub Narebski wrote:
quoted
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
From: Simon 'corecode' Schubert <hidden> Date: 2016-06-15 22:42:52
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 / \
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:42:52
On Fri, 2 Feb 2007, Lars Hjemli wrote:
On 2/2/07, Johannes Schindelin [off-list ref] wrote:
quoted
Hi,
On Fri, 2 Feb 2007, Jakub Narebski wrote:
quoted
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
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:42:52
On Fri, 2 Feb 2007, Andy Parkins wrote:
On Friday 2007 February 02 11:02, Lars Hjemli wrote:
quoted
"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
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:42:52
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
From: Lars Hjemli <hidden> Date: 2016-06-15 22:42:52
On 2/2/07, Nicolas Pitre [off-list ref] wrote:
On Fri, 2 Feb 2007, Lars Hjemli wrote:
quoted
On 2/2/07, Johannes Schindelin [off-list ref] wrote:
quoted
Hi,
On Fri, 2 Feb 2007, Jakub Narebski wrote:
quoted
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
From: Andy Parkins <hidden> Date: 2016-06-15 22:42:52
On Friday 2007 February 02 15:13, Nicolas Pitre wrote:
On Fri, 2 Feb 2007, Andy Parkins wrote:
quoted
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
From: Simon 'corecode' Schubert <hidden> Date: 2016-06-15 22:42:52
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 / \
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:42:52
On Fri, 2 Feb 2007, Andy Parkins wrote:
On Friday 2007 February 02 15:13, Nicolas Pitre wrote:
quoted
On Fri, 2 Feb 2007, Andy Parkins wrote:
quoted
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.
quoted
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?
quoted
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.
quoted
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.
quoted
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.
quoted
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.
quoted
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
From: Simon 'corecode' Schubert <hidden> Date: 2016-06-15 22:42:52
Simon 'corecode' Schubert wrote:
Lars Hjemli wrote:
quoted
"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 / \
From: Mark Wooding <hidden> Date: 2016-06-15 22:42:52
Andy Parkins [off-list ref] 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]
From: Andy Parkins <hidden> Date: 2016-06-15 22:42:52
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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:52
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
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:42:52
Johannes Schindelin [off-list ref] wrote:
On Fri, 2 Feb 2007, Lars Hjemli wrote:
quoted
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.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:52
Hi,
On Mon, 5 Feb 2007, Shawn O. Pearce wrote:
Johannes Schindelin [off-list ref] wrote:
quoted
On Fri, 2 Feb 2007, Lars Hjemli wrote:
quoted
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
From: Lars Hjemli <hidden> Date: 2016-06-15 22:42:52
On 2/5/07, Johannes Schindelin [off-list ref] wrote:
Hi,
On Fri, 2 Feb 2007, Lars Hjemli wrote:
quoted
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.