Carl Worth <cworth@xxxxxxxxxx> wrote: > But, whatever, if allowing fragile commits is seen as important by > those doing the work, who am I to complain about that? I'd just ask > that the following not be made slow: > > git checkout commit-from-beginning-of-time > git checkout master > > Thanks to the index, and the simplicity of what "git checkout" means, > checkout has always been blisteringly fast. All the talk of doing > reachability analysis scares me from a performance point of view, > (particularly when the _interesting_ cases (to me) of checkouts to > non-branches never need this anyway---since no commits will be made). The safety valve I was proposing would be only the additional time of running `git merge-base commit-from-begging-of-time master` to verify the former is completely contained in the latter. That's going to be true, and is a relatively fast operation (roughly linear in time with the length of the history). However in this case: git checkout v1.5.0 git checkout v1.2.0 would take slightly longer as we'd have to verify that the HEAD from the first checkout is contained in an existing tag/ref. Which it is. Since its probably exactly equal to one of those dereferenced tags this may just wind up being the cost of scanning the .git/packed-refs file. You do pack your refs, don't you? In my mind that is a small price to pay for making sure the commit currently in a detached HEAD doesn't get orphaned off into never-never land. -- Shawn. - 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