On Mon, 08 Jan 2007 17:05:26 -0800, Junio C Hamano wrote:
quoted text
> An obvious alternative is not to allow building on top of a HEAD
> that is detached at all, which I suggested initially.

That sounds great to me. Let's just suggest "checkout -b" before
commit, (maybe even add new "merge -b <newbranch>" and "commit -b
<newbranch>" so the suggest command could be even closer to what the
user wanted).

quoted text
> A non-alternative is to silently lose commits, which you seem to
> be suggesting, but I would rather play it safe.

No, I would never want that. We both agreed earlier that a safety
valve is necessary.

I just want to make sure that people that never actually need it don't
have to see the message. And I don't think that _that_ part would be
feasible with the safety valve at the point of "leaving detached
state". It would basically come down to having to do reachability
analysis for the current HEAD from all known branches or something
equally horrific.

So let's put the safety valve where it's cheap to detect and where we
know it will distinguish between read-only and read-write use, (that
is, put it precisely at the point where there's an attempt to create a
new commit object while in the detached state).

-Carl