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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 1, 2015, 22:22 UTC
Message-ID: <xmqq7fkx7qsa.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqegf57sfe.fsf@gitster.mtv.corp.google.com>

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

Show 11 quoted lines

> 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
>
> to do the obvious thing, perhaps?  We could even allow some form of
> extended SHA-1 expressions with some restrictions ...

Note that the above example already uses a form of extended SHA-1 expression, and I personally do not think we should support it in the very initial version.

This is because the actual object name, if resolved on the remote side, will not be known by "fetch". To support the "resolve on the remote end", we would need protocol extension to have the remote end tell the "fetch", i.e. "you asked to fetch HEAD@{4}, the exact object name for that is 030000f4c81729d2cb862a317e41a60a7111b98d"; otherwise we cannot add a line to FETCH_HEAD and cannot update the RHS of the refspec.

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

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. 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? 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".