On Thu, 15 Oct 2009, James Pickens wrote: > 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 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* -- 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