Thanks. Looks sane in a somewhat weird way; the series is internally consistent, and that is why I said "sane". An alternative would be not to checkout anything when HEAD points at an object that does not exist, or point the HEAD at the default "master" branch just like in the case when we cannot guess uniquely. That way, we do not have to worry about having to fetch the orphaned detached HEAD, which is an unlikely thing the publisher wanted to feed to its recipients in the first place. I tend to prefer the former (i.e. resulting in no paths in the working tree, possibly with a big warning message "the repository does not suggest which branch to track---are you sure you wanted to clone from there?"). Seriously. We treat the symbolic-ref on the publishing end not as the "current" branch at all. It is used as the "suggested primary branch to track". So allowing to fetch from a repository with detached HEAD is already a weird setup. I am hoping that we are not setting up origin/HEAD to point at anything in this case, as the remote is telling us that there is no suggested primary branch for the clients to track by having a detached HEAD to begin with. Even if you are fetching your own (or your pal's) repository with a working tree to transfer a work-in-progress, any work on detached HEAD that is orphaned is too transitory, and it goes against my taste to let people fetch from it. But people are free to have bad taste ;-). -- 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