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 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.
I think reducing users' exposure to the "detached HEAD" state would just
make it take longer for them to find that state familiar.
It's not like the concept is actually very difficult or unusual. CVS has
it as "cvs checkout -r <something>" or "cvs checkout -D <something>"; SVN
has it as "svn checkout -r <something>". It was weird and scary in CVS if
you did it (it was "sticky tags", and you had to find a different option
to get back to normal), but SVN is easier ("svn checkout -r HEAD").
I think the description used in CVS and SVN (and, I think, others) is that
you're not at the HEAD revision. I think they both account for the state
where you've checked out the revision by number that's the latest
revision, but you still can't grow the branch because you can't
simultaneously stay on r1000 (as requested explicitly) and add a new
commit.
So maybe the right explanation is:
$ git checkout master; git branch
* master
$ git checkout origin/master; git branch
* origin/master (not at head)
$ git checkout 123cafe^5; git branch
* 123cafe^5 (not at head)
$ git checkout HEAD^2; git branch
* 123cafe^5^2
$ git commit; git branch
* (temporary branch)
Then we can say that one way that git is different from SVN is that all
branches of other repositories are read-only, and you can't be at the
head when you're on them (because the head of those branches are in
different repositories); instead you grow the history locally, and you
tell the remote branch to adopt your history.
> 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
As far as I know, people don't actually seem to lose stuff this way. In
part, that's because they get scared before they get there; in part,
that's because they just don't think to go there; and in part, we tell
them how to recover stuff at that point (using the ref log or the sha1).
-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