git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] checkout: honor advice.detachedHead when reattaching to a branch
Date: Fri, 6 May 2011 21:38:47 -0400	[thread overview]
Message-ID: <20110507013847.GA25771@sigill.intra.peff.net> (raw)
In-Reply-To: <7vbozfxwon.fsf@alter.siamese.dyndns.org>

On Fri, May 06, 2011 at 03:59:20PM -0700, Junio C Hamano wrote:

> > 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 think we're probably in agreement on how to go forward, but I wanted
to note one final thing. It is actually not the list itself which is
that valuable to me. It's merely a convenience; if I know there is
something worth looking at, I am perfectly capable of inspecting the
history graph myself.

The real value in the orphan-check to me is whether it says "hey, there
are orphaned commits" or not. Before we had that check, leaving the
detached state _always_ said "Previous HEAD was...", and I quickly
learned to ignore it as uninteresting noise in 99% of the cases. Whereas
in the orphan warning case, I find that I want to do something about it
in at least 50% of the cases. Thus I actually heed the warning, and it
is effective.

It's possible that some people would find it useful to print only the
"warning: you are leaving orphaned commits" message, but not show the
list of them. I don't think it is worth it, though. Leaving orphaned
commits is the uncommon case, and doing so without wanting to
investigate is probably even less common. So the user is not too likely
to get annoyed by a little extra verbosity in the uncommon false
positive case.

-Peff

  parent reply	other threads:[~2011-05-07  1:38 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
2011-05-06 23:21     ` Jeff King
2011-05-07  1:38     ` Jeff King [this message]
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=20110507013847.GA25771@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).