Re: [PATCH] git-gui: give more advice when detaching HEAD

[Jeff King <peff@peff.net>]

On Fri, Feb 11, 2011 at 11:42:47PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> >   2. When leaving the detached state, notice that we have commits not
> >      contained in any other ref and pop up an "are you sure you want to
> >      lose these commits" dialog, with an option to create a branch. This
> >      is something we considered and rejected for the CLI, but I wonder
> >      if it makes more sense for git-gui.
> 
> Hmm, I don't recall the discussion on this for the CLI, but it intuitively
> feels like a good thing to do, unless it incurs an unacceptable cost.

I think one of the main concerns was cost, but I'm having trouble coming
up with the exact thread that I recall.

There is some discussion here, including Linus endorsing an exact-ref
check:

  http://article.gmane.org/gmane.comp.version-control.git/36428

There is a lot of back and forth, but I didn't have the patience to read
it all.

There is also this thread:

  http://thread.gmane.org/gmane.comp.version-control.git/94695

where one of the arguments against a leaving-detached safety valve seems
to be "well, we reflog the HEAD these days, so it's no big deal" (and
indeed, in this confused user case, the reflog did end up being the
recovery method).

I have a feeling there is another thread somewhere, but I can't find it.

> Temporarily detaching HEAD by scripts like rebase and am that know what
> they are doing should never have to pay the penalty, but an expert user
> who worked interactively on the detached HEAD can be made to wait for 0.2
> second more.

Is it that cheap? A full reachability check for something that is not in
any ref would involve going to the roots, wouldn't it? On linux-2.6,
that is something like 3s on my fast-ish machine. Though I guess using
commit-time cutoffs could make it really short (which reminds me, I
really need to clean up and post my patches to deal with clock skew).

> Your 1 and 3 both sound like sensible things to do, but I am not a good
> judge on them as I rarely if ever work in GUI.

That's kind of how I feel. I've never actually used git-gui beyond
trying to help users.

-Peff