Re: [RFC PATCH 0/4] Some patches for fsck for missing objects

From: Ben Peart <peartben@gmail.com>
Date: Jul 28, 2017, 13:40 UTC
Message-ID: <8c2266ad-586b-109e-1f99-a2315aa94c75@gmail.com>
In-Reply-To: <20170727102547.0c45a8db@twelve2.svl.corp.google.com>

On 7/27/2017 1:25 PM, Jonathan Tan wrote:

Show 6 quoted lines

> On Wed, 26 Jul 2017 23:42:38 +0000
> "brian m. carlson" <sandals@crustytoothpaste.net> wrote:
> 
>> I looked at this and I like the direction it's going.  It's pretty
>> simple and straightforward, which I also like.
>

ditto, simple is good!

Show 15 quoted lines

> Thanks.
> 
>> What I'd recommend is that instead of making lazyObject a string, we
>> make it an integer representing a protocol version.  We then add a
>> different config setting that is the actual program to invoke, using the
>> given protocol version.  This lets us change the way we speak to the
>> tool without breaking backwards compatibility, and it also allows us to
>> simply check the lazyObject script for supported protocols up front.
> 
> That's possible too. As for version negotiation, I think we'll end up
> using a protocol similar to the clean/smudge long-running process
> protocol (as documented as gitattributes), so that does not need to be
> taken care of here, but making lazyObject be the version integer is fine
> too.
>

I was also thinking the way to retrieve the missing objects be a versioned negotiation via the long-running process protocol.

That said, I'm a fan of including versions to make our life easier later if we decide to adopt an entirely different model for retrieving the missing objects.