Carl Worth <cworth@cworth.org> wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html