Re: [PATCH] Detached HEAD (experimental)

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jan 9, 2007, 23:44 UTC
Message-ID: <20070109234421.GD30023@spearce.org>
In-Reply-To: <87zm8ryiyz.wl%cworth@cworth.org>

Carl Worth <cworth@cworth.org> wrote:

Show 12 quoted lines

> 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.