Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was

On Wed, 14 Oct 2009, Jeff King wrote:

On Wed, Oct 14, 2009 at 03:34:05PM -0700, Junio C Hamano wrote:

quoted

quoted

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