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

From: Stefan Beller <sbeller@google.com>
Date: Nov 14, 2015, 00:10 UTC
Message-ID: <CAGZ79kaUZ08GXZjKtYNmRYOCQ0EQpsGd8+6PYFDU1LxYLw818g@mail.gmail.com>
In-Reply-To: <20151113234116.GA18234@sigill.intra.peff.net>

On Fri, Nov 13, 2015 at 3:41 PM, Jeff King <peff@peff.net> wrote:

Show 24 quoted lines

> On Fri, Nov 13, 2015 at 06:38:07PM -0500, Jeff King wrote:
>
>> On Fri, Nov 13, 2015 at 03:16:01PM -0800, Stefan Beller wrote:
>>
>> > Junio wrote on Oct 09, 2014:
>> > > This is so non-standard a thing to do that I doubt it is worth
>> > > supporting with "git clone".  "git clone --branch", which is about
>> > "> I want to follow that particular branch", would not mesh well with
>> > > "I want to see the history that leads to this exact commit", either.
>> > > You would not know which branch(es) is that exact commit is on in
>> > > the first place.
>> >
>> > I disagree with this. This is the *exact* thing you actually want to do when
>> > dealing with submodules. When fetching/cloning for a submodule, you want
>> > to obtain the exact sha1, instead of a branch (which happens to be supported
>> > too, but is not the original use case with submodules.)
>>
>> I think this is already implemented in 68ee628 (upload-pack: optionally
>> allow fetching reachable sha1, 2015-05-21), isn't it?
>
> Note that this just implements the server side. I think to use this with
> submodules right now, you'd have to manually "git init && git fetch" in
> the submodule. It might make sense to teach clone to handle this, to
> avoid the submodule code duplicating what the clone code does.

Yes I want to add it to clone, as that is a prerequisite for making git clone --recursive --depth 1 to work as you'd expect. (such that the submodule can be cloned&checkout instead of rewriting that to be init&fetch.

Thanks for pointing out that we already have some kind of server support.

I wonder if we should add an additional way to make fetching only some sha1s possible. ("I don't want users to fetch any sha1, but only those where superprojects point{ed} to", even if you force push a superproject, you want to want to only allow fetching all sha1s which exist in the current superprojects branch.)

Maybe our emails crossed, but in the other mail I pointed out we could use some sort of hidden ref (refs/superprojects/*) for that, which are allowed to mark any sort of sha1, which are allowed in the superproject/submodule context to be fetched.

So whenever you push to a superproject (a project that has a gitlink), we would need to check serverside if that submodule is at us and mark the correct sha1s in the submodule. Then you can disallow fetching most of the sha1s but still could have a correctly working submodule update mechanism.

Thanks, Stefan

>
> -Peff