Thread (28 messages) flat view 28 messages, 10 authors, 2016-06-15

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

From: Nicolas Pitre <hidden>
Date: 2016-06-15 22:42:52

Possibly related (same subject, not in this thread)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help