On Wed, Oct 14, 2009 at 4:09 PM, Jeff King <peff@xxxxxxxx> wrote: > That makes the most sense to me. If "git checkout" could write metadata > into HEAD (or into DETACH_HEAD, as in Daniel's patch), then checkout > could record an "ok to commit" bit. And could also be used to change it > after the fact. E.g.: > > $ git checkout --detach=commit origin/master > $ git commit ;# should be ok > > $ git checkout --detach=examine origin/master > $ git commit ;# complain > $ git checkout --detach=commit HEAD > $ git commit ;# ok > > I guess something like "rebase" should detach with "ok to commit", since > it is planning on attaching the commits later. I'm not sure about "git > bisect". I guess probably it should be "not ok to commit" to be on the > safe side, and then somebody can "git checkout --detach=commit" if they > want to. How about not detaching the head at all if the user checks out any ref, and reject commits if he checked out a tag or remote branch. For example: $ git checkout origin/master $ git status # On branch origin/master $ git commit ;# complain $ git checkout v1.0.1 $ git status # On tag v1.0.1 $ git commit ;# complain $ git checkout v1.0.1^0 ;# detach $ git commit ;# ok I think this would help the newbies and wouldn't cost the experts too much. Checking out anything other than a plain ref would still detach the head, and commits on a detached head would still be allowed. Perhaps as an additional safety feature, Git could refuse to switch away from a detached head if the head isn't reachable from any ref, and require -f to override: $ git checkout $sha1 $ git commit $ git checkout master ;# complain $ git checkout -f master ;# ok Maybe I'm missing something and this all can't be done, but it seems simpler than the other options I've seen in this thread. James -- 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