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

On Thu, 15 Oct 2009, James Pickens wrote:

On Wed, Oct 14, 2009 at 4:09 PM, Jeff King [off-list ref] wrote:

quoted

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 origin/master
 $ git fetch
 $ git checkout origin/next
 Uncommited file '...' would be overwritten.

If HEAD is a symref to refs/remotes/origin/master, and you update 
refs/remotes/origin/master, git will subsequently see that your index 
doesn't match HEAD, and when you switch branches, it will try to apply a 
revert to the branch you're switching to. It's the same issue as pushing 
into a non-bare repository.

	-Daniel
*This .sig left intentionally blank*