On Wed, Nov 6, 2013 at 1:41 PM, Carlos Martín Nieto <c...@elego.de> wrote:
> On Wed, 2013-11-06 at 12:32 -0800, Junio C Hamano wrote:
>> I'll queue these for now, but I doubt the wisdom of this series,
>> given that the ship has already sailed long time ago.
>> Currently, no third-party implementation of a receiving end can
>> accept thin push, because "thin push" is not a capability that needs
>> to be checked by the current clients. People will have to wait
>> until the clients with 2/2 patch are widely deployed before starting
>> to use such a receiving end that is incapable of "thin push".
>> Wouldn't the world be a better place if instead they used that time
>> waiting to help such a third-party receiving end to implement "thin
>> push" support?
> Support in the code isn't always enough. The particular case that
> brought this on is one where the index-pack implementation can deal with
> thin packs just fine.
> This particular service takes the pack which the client sent and does
> post-processing on it to store it elsewhere. During the receive-pack
> equivalent, there is no git object db that it can query for the missing
> base objects. I realise this is pretty a unusual situation.
At Google we have made effort to ensure servers can accept thin packs,
even though its clearly easier to accept non-thin, because clients in
the wild already send thin packs and changing the deployed clients is
harder than implementing the existing protocol.
If the server can't complete the pack, I guess this also means the
client cannot immediately fetch from the server it just pushed to?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html