From: Ben Peart Date: Fri, 28 Jul 2017 13:40:50 GMT Subject: Re: [RFC PATCH 0/4] Some patches for fsck for missing objects 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: > On Wed, 26 Jul 2017 23:42:38 +0000 > "brian m. carlson" 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! > 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.