I do not want to think about the consequences of adding more
cruft under .git/ directory. For example, should PREV be
noticed by fsck and prune? What should various forms of
'git-reset' do with it? How does it interact with 'git-bisect'?
Being able to test merge or even make commits without being on a
branch is vastly useful. It might or might not lead to anywhere
even after you make a handful commits -- and I would imagine
that it would be very handy to be able to be lazy and not having
to decide if it is worth a new branch.
But that may be just my imagination; I generally prefer any
feature that allows me to defer decision over something that
makes me decide early. If Carl wants to do a patch to teach
'git-commit' (and all other things that can create commits) not
to do things from working in a detached HEAD, I would probably
not opposed to it too much, but I am fairly certain that I won't
be coding it myself.
It's tempting to forget about this whole "safety" business.
Because we allow "reset --hard" and other forms of operations
that can lose history if they were done while on a branch, only
giving the safety to "git checkout" feels somewhat silly. And
the primary motive for detached HEAD as I understand it is for
sightseeing, and not allowing "reset --hard" to jump around is
just plain silly.
That is, after:
git checkout v1.4.0
you are not on any branch, and we would still allow
git reset --hard v1.2.0
which is exactly the same as:
git checkout v1.2.0
You can still say:
git checkout master
and we do not even check.
Which makes the "merge-base --check-ancestry" stuff I did last
night pretty much unnecessary, but that's Ok. It will find
other uses.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
