Re: [PATCH 0/2] thin-pack capability for send-pack/receive-pack

Carlos Martín Nieto [off-list ref] writes:

On Wed, 2013-11-06 at 12:32 -0800, Junio C Hamano wrote:

quoted

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.

OK, I agree that it sounds quite niche-y, but it still is sensible.
If a receiving end does not want to (this includes "it is incapable
of doing so", but does not have to be limited to) complete a thin
pack, the series will give it such an option in the longer term.

Thanks.