From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] checkout: honor advice.detachedHead when reattaching to a branch
Date: Fri, 06 May 2011 15:59:20 -0700 [thread overview]
Message-ID: <7vbozfxwon.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20110506223847.GC17848@sigill.intra.peff.net> (Jeff King's message of "Fri, 6 May 2011 18:38:47 -0400")
Jeff King <peff@peff.net> 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.
next prev parent reply other threads:[~2011-05-06 22:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-06 20:35 [PATCH] checkout: honor advice.detachedHead when reattaching to a branch Junio C Hamano
2011-05-06 22:38 ` Jeff King
2011-05-06 22:59 ` Junio C Hamano [this message]
2011-05-06 23:21 ` Jeff King
2011-05-07 1:38 ` Jeff King
2011-05-24 17:11 ` Junio C Hamano
2011-05-24 20:27 ` Jeff King
2011-05-24 21:24 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vbozfxwon.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).