I am not saying being risky is useful. That's why I said it is
experimental.
We could do two things, and I think disallowing commits is not
necessarily a better option of the two. We could allow commits
and prevent the user from switching out of the detached HEAD
state without an explicit action instead. If we go the first
route, you need to also prevent merges into the detached HEAD.
If we go the latter I think you only need to add a check in
"git-checkout" but there may be other cases. In either way, we
need a safety valve, which the experimental code does not have.
And being able to merge into the detached HEAD turns out to be
somewhat useful. I checked out the v1.4.4.3 and tried to see if
a topic is applicable by merging into that detached HEAD and
running testsuite. Of course, without any safety valve, I can
easily lose the merge result by switching out of the detached
HEAD state (say, "git checkout master"), but on the other hand,
creating a new branch at that point with "git checkout -b
v1.4.4.3-maint" would let me continue from that point without
losing anything.
But this is only "somewhat" -- I do not have strong opinion
either way, other than that we need a safety valve (which we
agree).
In any case, I did this because I got tired of waiting for it to
happen (I thought you wanted to hack on this over the long
week^W yearend, so I deliberately stayed away from doing this)
and I was bored. This will not be in 'next' in the current
shape.
You've thought about the issue long enough to write your
commentary and I agree to most of your points (including
favoring "no commit allowed in this state" over "allow commits
and merges to help advanced usage" for its simplicity), so if
you code it up with a clean patch, I would not reject it on the
basis of its design.
-
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
