On Mon, 08 Jan 2007 17:05:26 -0800, Junio C Hamano wrote: > 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). > 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
Attachment:
pgpxl31KJrEZc.pgp
Description: PGP signature