On Tue, 9 Jan 2007, Junio C Hamano wrote:
>
> Being able to test merge or even make commits without being on a
> branch is vastly useful.
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
-
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