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

Jeff King [off-list ref] writes:

On Fri, May 06, 2011 at 01:35:37PM -0700, Junio C Hamano wrote:

quoted

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.