Re: [PATCH] Detached HEAD (experimental)

On Tue, 9 Jan 2007, Junio C Hamano wrote:

Yes. I think the detached head notion is really really important. I think it was a mistake to not allow it initially, but hey, there were various historical reasons, and the whole thing about how branches worked was a bit up in the air.

I would suggest a solution:

 - git checkout will refuse to switch AWAY from a detached head unless the 
   SHA1 of the detached head exactly matches some other branch.

Not any expensive "reachability" cheaks. Simple and straightforward: just say "no, I will not leave this branch-less HEAD behind, because it is not described by any other branch or tag".

So if you do

	git checkout v1.4.4

you'll be fine, because even though you got a detached HEAD that isn't attached to any branch, it still exists as a tag, so checking out something else is fine - you've not lost any state.

In contrast, if you actually start committing to that detached HEAD, you need to either

 - use some new flag ("git checkout --forget-old") to explicitly say that 
   you _want_ to leave this old naked branch behind

 - either tag the current point or make a real branch out of it (with 
   either "git tag <tagname>" or "git branch <branchname>" respectively) 
   and then you can check out some other tag/branch after that.

Doing "reachability analysis" is not only expensive, it's actually really wrong, because even if the current HEAD is _reachable_ from some other tag or branch, you're still going to drop that point in the development series unless it _exactly_ matchs it.

Hmm?

I'd love to see the detached HEAD series move into "master", but I do think we should make sure that people can't drop their work easily by mistake, and I think the above suggestion is both simple and workable.

Comments?

		Linus