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

From: Stefan Beller <sbeller@google.com>
Date: Dec 3, 2015, 20:03 UTC
Message-ID: <CAGZ79kbtOEMk2woY5rovvC4xduiQRsKp+BXVt=5h9d76tpLWSA@mail.gmail.com>
In-Reply-To: <xmqq7fkx7qsa.fsf@gitster.mtv.corp.google.com>

On Tue, Dec 1, 2015 at 2:22 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I do not think you would need a new option for this, by the way.
>> Just add a new syntax for the LFS of a refspec that cannot possibly
>> be confused with existing choices of what can come there (i.e. an
>> empty string to denote deletion, or a partial refname), e.g. come up
>> with an appropriate string in $sign and allow the following:
>>
>>     $ git fetch ${sign}c78f7b5ed9dc
>>     $ git fetch ${sign}c78f7b5ed9dc:refs/remotes/origin/frotz

That looks good to me.

>
> Instead, we should limit us to 40-hex object name and nothing else
> in the initial incarnation.

ok, will do.

Show 16 quoted lines

>
> i.e.
>
>      $ git fetch ${sign}c78f7b5ed9dc1c6edc8db06ac65860151d54fd07
>      $ git fetch ${sign}c78f7b5ed9dc1c6edc8db06ac65860151d54fd07:refs/remotes/origin/frotz
>
> If the remote end (which, as Peff pointed out earlier, already knows
> how to respond to a fetch request for an exact object when
> configured to do so) allows such a fetch to go through, "fetch" can
> (and will) update the ref named by the RHS of storing refspec with
> the current code, so there is no need to do anything special to
> support this.
>
> As to ${sign}, I was tempted to say an empty string might be
> sufficient (i.e. "do not use 40-hex as your branch name"), but it
> probably is a bad idea.

I would think if sign is empty string the server will check if the given 40-hex is unique (either a branch named so, while there is no such object or just that object and not branch/tag) or the remote would reject due to disambiguation. This possibility can be done later though.

Show 6 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.

> That is leading "." denotes "this is an extended refspec"
> and the next character denotes what kind of extended refspec it is.
> For now we say that "@" denotes "exact object name is used instead
> of a(n abbreviated) refname".

So using @ as you propose I could also specify .@refs/heads/master as an un-abbreviated ref?

Did you have any reason to pick . specifically or are we welcome to bikeshed why a colon might be better? (or ":", "?", "[", "\", "^", "~", SP, or TAB)

We could use [id]c78f7b5ed9dc1c6edc8db06ac65860151d54fd07 or [const]c78f7b5ed9dc1c6edc8db06ac65860151d54fd07 ?

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