From: Junio C Hamano <gitster@pobox.com>
To: "Carlos Martín Nieto" <cmn@elego.de>
Cc: git@vger.kernel.org, jrnieder@gmail.com, pclouds@gmail.com
Subject: Re: [PATCH 0/2] thin-pack capability for send-pack/receive-pack
Date: Wed, 06 Nov 2013 14:25:50 -0800 [thread overview]
Message-ID: <xmqqvc056uc1.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1383774082.2850.10.camel@centaur.cmartin.tk> ("Carlos Martín Nieto"'s message of "Wed, 06 Nov 2013 22:41:22 +0100")
Carlos Martín Nieto <cmn@elego.de> writes:
> 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.
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.
next prev parent reply other threads:[~2013-11-06 22:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 15:04 [PATCH 0/2] thin-pack capability for send-pack/receive-pack Carlos Martín Nieto
2013-11-06 15:04 ` [PATCH 1/2] receive-pack: advertise thin-pack Carlos Martín Nieto
2013-11-06 15:04 ` [PATCH 2/2] send-pack: only send a thin pack if the server supports it Carlos Martín Nieto
2013-11-06 20:32 ` [PATCH 0/2] thin-pack capability for send-pack/receive-pack Junio C Hamano
2013-11-06 21:41 ` Carlos Martín Nieto
2013-11-06 22:25 ` Junio C Hamano [this message]
2013-11-06 22:54 ` Jeff King
2013-11-06 23:47 ` Shawn Pearce
2013-11-06 23:42 ` Shawn Pearce
2013-11-23 15:09 ` Carlos Martín Nieto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqvc056uc1.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=cmn@elego.de \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.