On Wed, Jun 01, 2011 at 06:47:54PM -0400, Jeff King wrote: > > Probably. As HEAD is usually visible via ls-remote exchange, the usual > > security concern would not come into the picture even if we do (1), even > > though it feels somewhat wrong to do. > > Yeah, one can always just do: > > git fetch origin HEAD && git checkout FETCH_HEAD > > immediately afterwards. But I think given that we make some effort to > propagate detached-ness across a clone in cases where we can, we should > just do the fetch. Re-reading what I wrote, it's horribly unclear. What I meant was: We already make some effort to propagate detached-ness across a clone in cases where the detached commit is found in referenced history. To not do so for the case where the detached commit is not an ancestor of any ref seems unnecessarily inconsistent. Therefore we should solve the problem not by refusing to handle the detached HEAD, but by correctly fetching the objects. -Peff -- 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