On Mon, 11 Jul 2005, Linus Torvalds wrote:
> No, git-checkout-script _shouldn't_ have done that. It will do the
> read-tree on the tag (which will do the right thing), but it won't change
> the HEAD itself.
In preparation of actually updating the HEAD, I just made "git checkout"
verify that it only checks out a commit, not a tree tag or something like
that. Too late for Marc, but next time around a "git checkout v2.6.11"
will result in
[EMAIL PROTECTED] linux]$ git checkout v2.6.11
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a
Needed a single revision
That's not exactly _obvious_ either, but hey, it's at least a half-way
readable and understandable error, and it's obviously correct to somebody
who knows how git works.
That still leaves the question about what to do when you do
git checkout v2.6.12
which _is_ a valid operation. Right now it will "check out" that tag, in
the sense that it will make the working tree correspond to v2.6.12, but it
won't actually touch HEAD at all. The question is, what _should_ it do to
Should it just reset HEAD to point to .git/refs/master, and then write the
commit ID to it? That may actually sometimes be exactly what you want, and
at least it will result in a consistent state (ie the next commit will
have the right parent). On the other hand, it will blow away whatever the
old "master" branch contained, and thus likely leave an unreachable
On the other hand, creating a new branch might be a but surprising to
people: "But I just wanted to check it out". But as far as I can see, it's
the only safe thing to do, and it has the advantage that you can then go
back to the old state with a simple "git checkout master".
But what about the branch name? Should we just ask the user? Together with
a flag, like
git checkout -b new-branch v2.6.12
for somebody who wants to specify the branch name? Or should we pick a
random name and add a helper function to rename a branch later?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html