Johan Herland [off-list ref] writes:
It seems to have been suggested (in various forms) by several people and
generally well-received in the original thread, but nothing seems to have
come of it (at least nothing that has survived till today).
You are masochistic enough to have noticed that people were talking about
the safety in the context of "HEAD lacks its own reflog"? Yes, we had
reflogs on each refs/*, but HEAD itself did not have one.
The situation has changed --- HEAD has its own reflog these days, which
not only helps this particular issue but is useful in contexts that never
involves a detached HEAD.
On Wednesday 03 September 2008, Junio C Hamano wrote:
Johan Herland [off-list ref] writes:
quoted
It seems to have been suggested (in various forms) by several
people and generally well-received in the original thread, but
nothing seems to have come of it (at least nothing that has
survived till today).
You are masochistic enough to have noticed that people were talking
about the safety in the context of "HEAD lacks its own reflog"? Yes,
we had reflogs on each refs/*, but HEAD itself did not have one.
Yes, I noticed that...
The situation has changed --- HEAD has its own reflog these days,
which not only helps this particular issue but is useful in contexts
that never involves a detached HEAD.
...and that is certainly good, but I wonder if the people we want to
protect from losing detached commits might not be aware of the
existence and usage of reflogs (since we already assume they might not
yet have fully grasped the branch concept). Even so, this would provide
a golden opportunity to teach them about it. So, what about this:
When switching away from a detached HEAD that will cause it to become
unreachable, we should warn the user of what is happening, and how to
recover from this situation. I.e. something like:
The commit you switched away from is not reachable from an existing
ref, and will be deleted when its reflog entry expires (in $X days).
See "git help reflog" for more information.
If you want to keep this commit, you must bind it to a ref, for
example by doing
git branch <new-branch-name> $SHA1_SUM_HERE
Of course, this warning can be hidden by giving -q to git checkout.
Hmm?
Hopefully no longer masochistic,
...Johan
--
Johan Herland, [off-list ref]
www.herland.net