Re: "git symbolic-ref" doesn't do a very good job

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux