Re: [PATCH 0/2] thin-pack capability for send-pack/receive-pack
- From
Shawn Pearce <spearce@spearce.org>
- Date
- Nov 6, 2013, 23:42 UTC
- Message-ID
- <CAJo=hJtUMZit8Mtt7NQ=SiAXmnHf3xQqCKMo3F3XksHoq0tCkw@mail.gmail.com>
- In-Reply-To
- <1383774082.2850.10.camel@centaur.cmartin.tk>
On Wed, Nov 6, 2013 at 1:41 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
Show 23 quoted lines
> 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.
How... odd?
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?