git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roy E <royeldar0@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, jonathantanmy@google.com
Subject: Re: [PATCH RESEND 2/2] status: improve info for detached HEAD after clone
Date: Fri, 10 Mar 2023 18:25:26 +0200	[thread overview]
Message-ID: <CAOfFamk5wWFuUgn4uEo0JV0siLzH=ybDB_Yr-9oL3OM4taozuA@mail.gmail.com> (raw)
In-Reply-To: <xmqqsfefrn4q.fsf@gitster.g>

Hi,

First of all, thanks for the thoughtful response.

Junio C Hamano <gitster@pobox.com> writes:

> - Adding new code here would mean that the result of parsing @{-1}
>   and what wt_status_get_detached_from() will report becomes
>   inconsistent, no?

If I understand correctly, the result of parsing @{-1} is the commit
checked out before the current one, so grab_nth_branch_switch() gets
the commit we've moved _from_, whereas wt-status::grab_1st_switch()
gets the commit we've moved _to_. After a clone, there is no commit
we've moved _from_.

> Yes, the head may be detached at some object that is not a local or
> remote branch.  But what is so bad about reporting the fact
> faithfully, i.e., that we are not on any branch?

I thought that we try to avoid showing "Not currently on any branch"
as this message is not very user-friendly (see commit b397ea4).
Furthermore, showing "HEAD detached at X" where X is the abbreviated
hash is more consistent with the behavior of the detached HEAD advice
in "git clone", which says

        Note: switching to 'X'

> I personally do not very much appreciate the extra info that is
> given by saying "HEAD detached at X" and "HEAD detached from X",
> compared to saying just "Not currently on any branch", especially
> when these X are not concrete branch names or tag names but just
> hexadecimal string that needs to be fed to "git describe" to be
> turned into something that makes sense to humans

It might be better to show "HEAD detached at X" where X is the concrete
tag name which was cloned; but since "grab_1st_switch" digs in the
reflog for that information, one cannot figure out the tag name that
was used when the repository was cloned. I didn't want to complicate
the current logic too much, and IMHO showing the abbreviated hash is
the best thing we can do, and it is already what we do in certain cases
(e.g. after "git checkout --detach").

      reply	other threads:[~2023-03-10 16:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 19:20 [PATCH RESEND 0/2] status: improve info for detached HEAD Roy Eldar
2023-03-08 19:20 ` [PATCH RESEND 1/2] t7508: test status output for detached HEAD after clone Roy Eldar
2023-03-08 19:20 ` [PATCH RESEND 2/2] status: improve info " Roy Eldar
2023-03-08 20:42   ` Junio C Hamano
2023-03-10 16:25     ` Roy E [this message]

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='CAOfFamk5wWFuUgn4uEo0JV0siLzH=ybDB_Yr-9oL3OM4taozuA@mail.gmail.com' \
    --to=royeldar0@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jonathantanmy@google.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).