Jeff King <peff@xxxxxxxx> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html