Re: [PATCH] checkout: honor advice.detachedHead when reattaching to a branch

From: Junio C Hamano <gitster@pobox.com>
Date: May 6, 2011, 22:59 UTC
Message-ID: <7vbozfxwon.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110506223847.GC17848@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 40 quoted lines

> On Fri, May 06, 2011 at 01:35:37PM -0700, Junio C Hamano wrote:
>
>> When switching away from a detached HEAD with "git checkout", we give a
>> final warning to tell how to resurrect the commits being left behind since
>> 8e2dc6a (commit: give final warning when reattaching HEAD to leave commits
>> behind, 2011-02-18) rather loudly.
>> 
>> This is a good safety measure for people who are not comfortable with the
>> detached HEAD state, but the warning was given even to those who set the
>> advice.detachedHead to false to decline the warning given when detaching,
>> resulting in an asymmetric experience.  Silent when going detached, and
>> very loud when coming back.
>
> I'm somewhat negative on this. I think there are actually 5 distinct
> pieces of information that git currently gives in going to and from a
> detached HEAD, and the motivations for suppressing them may be
> different:
>
>   1. On detaching, we indicate briefly that the HEAD has been detached
>      by saying "HEAD is now at ..." instead of "Switched to branch ...".
>
>   2. On detaching, we give a large warning on what the detached HEAD
>      state means, and advise on how to get out of it.
>
>   3. On leaving, if there are no orphaned commits, we indicate briefly
>      where the previous HEAD position was with "Previous HEAD position
>      was...".
>
>   4. On leaving, if there are orphaned commits, we list them.
>
>   5. On leaving, if there are orphaned commits, we give advice on how to
>      make branches out of them.
>
> Right now, advice.detachedhead suppresses (2); that is, we leave the
> short indicator that provides distinct per-use information to the user
> (1), but suppress the lengthy advice that is not helpful to advanced
> user.
>
> So if you wanted symmetry, I think that would mean suppressing (5), but
> leaving (4), which contains per-use information, intact.

The patch does leave per-use information by giving 3. "HEAD was" as you noted above, and that is more than sufficient (you can also look at HEAD@{0}). If and only if the list is needed (i.e. the user wants to recover), the user can run "git log $that_commit".

> I can also see somebody wanting to suppress (4), either because it takes
> too much time to compute, or because even though there is distinct
> information in the message, it is lengthy. But I think that should be a
> separate knob.

Ok, then a separate configuration that is.

> I tend to think (3) is now just useless.

Quite the contrary. If you do not want to pay the price of (4) that is useless most of the time, (3) is a cheap, space efficient and useful information that is essential to allow you to get rid of (4) without having to look at reflog.