Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 4, 2015, 15:32 UTC
Message-ID: <xmqqd1umteja.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kbtOEMk2woY5rovvC4xduiQRsKp+BXVt=5h9d76tpLWSA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 15 quoted lines

>> A single dot "." would be a possibility
>> (i.e. a ref component cannot begin with a dot), but squating on it
>> and saying "anything that begins with . must be followed by 40-hex
>> (and in the future by an extended SHA-1)" would rob extensibility
>> from us, so perhaps ".@c78f7b5ed9dc1c6edc8db06ac65860151d54fd07" or
>> something?
>
> My gut reaction is to reject that notation, as it is very cryptic.
> Looking at the @ sign, it reminds me of the reflog notion such as HEAD@{-1}.
> So maybe it would be more appealing to specify
> HEAD@{c78f7b5ed9dc1c6edc8db06ac65860151d54fd07}
> to mean a specific commit. By saying HEAD we indicate it is not meant as
> a branch (both on the remote as well as locally).
> By having the @{ sequence this would also be dis-ambiguous from any
> branch.

I specifically rejected that when I wrote the message you are responding to, because I think that would make it harder to later enhance the mechanism to ask for HEAD@{...}, i.e. extended SHA-1 expression.

But bikeshedding can be left as an exercise to those who have too much time on hand.

> Looking at the big picture here, this being a preparation for improving
> submodule cloning, we also want to allow tags here?

The reason why we need to restrict to raw 40-hex in the initial iteration is because we do not want protocol update for an uncooked idea. Hence a tag object name in 40-hex is fine, but a tag refname e.g. v1.0 is not.