On Thu, Oct 30, 2014 at 3:03 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> At some stage it may becomes too many preferences and over-engineered.
>> Maybe I should drop this patch and then just require the plain "if you
>> want a push to be atomic, then use --atomic-push. end." and we
Ronnie Sahlberg writes:
> At some stage it may becomes too many preferences and over-engineered.
> Maybe I should drop this patch and then just require the plain "if you
> want a push to be atomic, then use --atomic-push. end." and we have
> simple and easy to understand semantics.
As I still do
On Thu, Oct 30, 2014 at 1:11 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> Add receive.preferatomicpush setting to receive-pack.c. This triggers
>> a new capability "prefer-atomic-push" to be sent back to the send-pack
>> client, requesting the client, if it supports it, to request
>>
Ronnie Sahlberg writes:
> Add receive.preferatomicpush setting to receive-pack.c. This triggers
> a new capability "prefer-atomic-push" to be sent back to the send-pack
> client, requesting the client, if it supports it, to request
> an atomic push.
I can understand a configuration that says "We
Add receive.preferatomicpush setting to receive-pack.c. This triggers
a new capability "prefer-atomic-push" to be sent back to the send-pack
client, requesting the client, if it supports it, to request
an atomic push.
This is an alternative way to trigger an atomic push instead of having
to rely o
5 matches
Mail list logo
