On Wednesday 03 September 2008, Junio C Hamano wrote:
> Johan Herland <johan@xxxxxxxxxxx> 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.
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, <johan@xxxxxxxxxxx>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
