On Wed, 14 Oct 2009, Jeff King wrote: > On Wed, Oct 14, 2009 at 03:34:05PM -0700, Junio C Hamano wrote: > > > > Agreed. Presumably some expert mode config would imply -f > > > automatically. > > > > No, I do not want an expert mode. I can probably live with "per session" > > setting, that makes me decide to set or not set it when I detach, though. > > 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. Whatever is done about this... I'm afraid Git will end up less useful as operations that were possible before won't be anymore for "security's sake" unless some obnoxious override mode is involved. Isn't the reflog already dealing with the security issue by making sure that nothing is "lost"? Can't the user confusion be dealt with through some means other than making the tool less flexible? I don't mind extra help message to be displayed after a headless commit is made for example. But trying to make the tool more friendly should perhaps come from better education rather than added restrictions. My thoughts only. Nicolas -- 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