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

From: Jeff King <peff@peff.net>
Date: Feb 12, 2011, 08:04 UTC
Message-ID: <20110212080456.GA18380@sigill.intra.peff.net>
In-Reply-To: <7v8vxlzojs.fsf@alter.siamese.dyndns.org>

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

Show 10 quoted lines

> 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