All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Git List Mailing <git@vger.kernel.org>
Subject: Re: "git symbolic-ref" doesn't do a very good job
Date: Mon, 01 Aug 2022 17:57:30 -0700	[thread overview]
Message-ID: <xmqqilnbjwcl.fsf@gitster.g> (raw)
In-Reply-To: <Yuhz0VAX77qv4P5Z@coredump.intra.peff.net> (Jeff King's message of "Mon, 1 Aug 2022 20:46:09 -0400")

Jeff King <peff@peff.net> writes:

> On Mon, Aug 01, 2022 at 11:54:36AM -0700, Junio C Hamano wrote:
>
>> > +test_expect_success 'symbolic-ref allows top-level target for non-HEAD' '
>> > +	git symbolic-ref refs/heads/top-level FETCH_HEAD &&
>> > +	git update-ref FETCH_HEAD HEAD &&
>> > +	test_cmp_rev top-level HEAD
>> > +'
>> >  test_done
>> 
>> Strange, but OK.
>
> I'd be OK to drop this if you hate it too much, btw. Mostly I wanted to
> make sure that the various iterations behaved as I expected. But there
> is a test in t3200 (the one Linus found earlier) that incidentally does
> check that something like this works.

Oh, no, I do not hate it (or like it) at all.

The "strange" was mostly referring to the order of the symbolic
thing that refers to another thing that is being pointed at, which
looked backwards, i.e. "git symbolic-ref HEAD refs/heads/main" is
what we usually expect (i.e. "we use this short name HEAD to refer
to the longer refs/heads/main ref"), but after staring the one in
the test "git symbolic-ref refs/heads/top-level FETCH_HEAD" too
long, your eyes trick your brain into thinking we use the short name
FETCH_HEAD to refer to the top-level branch, which is the other way
around.

We've been allowing the one-level thing and I think the discussion
has established that we need to keep it supported.  There is nothing
to hate or like about it X-<.

Thanks.


  reply	other threads:[~2022-08-02  0:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-30 19:53 "git symbolic-ref" doesn't do a very good job Linus Torvalds
2022-07-30 20:21 ` Linus Torvalds
2022-07-30 20:38   ` Junio C Hamano
2022-07-31  0:18   ` Jeff King
2022-07-31  0:24     ` Jeff King
2022-07-31  0:44       ` Linus Torvalds
2022-08-01 17:43         ` Jeff King
2022-08-01 17:46           ` Jeff King
2022-08-01 18:15           ` Jeff King
2022-08-01 18:54             ` Junio C Hamano
2022-08-02  0:46               ` Jeff King
2022-08-02  0:57                 ` Junio C Hamano [this message]
2022-08-01 19:00             ` Linus Torvalds
2022-07-31 19:10     ` Junio C Hamano
2022-08-01 17:36       ` Jeff King
2022-08-01 17:49         ` Linus Torvalds
2022-08-01 18:04           ` Jeff King

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=xmqqilnbjwcl.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.