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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 1, 2015, 21:47 UTC
Message-ID: <xmqqegf57sfe.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACsJy8CFCu4casNn25b1YPkV==-8kDy3wzYd5uf794R41M0Y9w@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 12 quoted lines

> maybe
>
> git clone --commit-id <sha1> repo (*)
>
> instead. Detached head is implied, and this way you don't have to
> disambiguate sha-1 vs refname. And --commit-id can also be added in
> git-fetch. Actually the git-fetch case is even more interesting, what
> do we do with refspec..
>
> (*) as usual, we accept committish sha-1, not just comit sha-1, so
> --commit-id may be confusing..? Or maybe just go with --tag where we
> accept either tag names, tag sha-1 or commit-sha1

I agree with you that it is sensible to think this topic around "fetch" not "clone".

I however do not think "--commit-id" is a good name for that option. You are naming the option after what it is that is given, not after what the commit specified with that commit-id is used for. It is just as nonsense as renaming the "--not-merged" option used in "branch --not-merged $commit" to "--commit-id" because the option takes the object name for a committish.

Besides, "git fetch" can grab any object, not limited to committish, which makes "--commit-id" a doubly unsuitable name for the option.

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 (e.g. limit its use in a protected friendly environment to avoid excessive resource use at the server side):

    $ git fetch ${sign}c78f7b5ed9dc~12
    $ git fetch ${sign}HEAD@{4}:refs/remotes/origin/frotz

The ${sign} signals two things. (1) That the endpoint of the history (or the name of the object being fetched, be it a blob, a tree and all its contents, a commit and everything reachable from it, etc.) is specified and (2) that the specification will be interpreted at the remote side.

Hmm?