Re: Some issues when trying to set up a shallow git mirror server

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 8, 2016, 10:44 UTC
Message-ID: <CACsJy8CBj-oMTLrn8gVudhLPEixZfkwFv9BaN8LSNFvOHkqKkg@mail.gmail.com>
In-Reply-To: <20160108101903.GC3397@logi.codethink.co.uk>

On Fri, Jan 8, 2016 at 5:19 PM, Richard Maw <richard.maw@codethink.co.uk> wrote:

Show 21 quoted lines

> On Thu, Jan 07, 2016 at 10:00:07AM -0800, Junio C Hamano wrote:
>> Richard Maw <richard.maw@codethink.co.uk> writes:
>> > This is inconvenient for us,
>> > as we were explicitly using refspecs which didn't force the fetch,
>> > since we were using the "non fast-forward update" errors
>> > to detect whether upstream force pushed important refs
>> > which could be a sign of tampering.
>> >
>> > While the client doesn't have enough information
>> > the server has those commits.
>> > Would it make sense for the server to be able to tell the client
>> > "trust me, that commit is a descendant of the previous one"?
>>
>> It does not in our security model, as you do not blindly trust the
>> other side, whether you are a "client" or a "server".
>
> Fair enough.
> I didn't know whether Git passed responsibility for that to the transport layer.
>
> Would a mode for fetch to also include the commit chain without the trees fit
> the security model?

It sounds a lot like what I did with narrow clone [2] prototype. A narrow clone only contains enough objects for certain paths so there's a chance that we just don't have enough to do a proper merge. A server-side command was added [1] to retrieve enough objects for the task. If you fetch commit chain without all necessary trees and objects, your repo is "broken" from Git point of view and you'll need to do some extra work to make sure your repo is not actually broken.

[1] http://article.gmane.org/gmane.comp.version-control.git/154371 [2] http://thread.gmane.org/gmane.comp.version-control.git/154343

-- 
Duy