Re: [PATCH 6/8] receive-pack.c: add a receive.preferatomicpush configuration variable
Ronnie Sahlberg sahlb...@google.com 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 take only atomics when a push tries to update more than one, but this one is iffy. If the receiver accepts non-atomic from older send-pack, those with newer send-pack should have a way to say the receiving end may prefer atomic, but I choose not to. Is there a way to do so? And if there is such a way, what value does the preference add to the user experience and the server's operation? -- 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
Re: [PATCH 6/8] receive-pack.c: add a receive.preferatomicpush configuration variable
On Thu, Oct 30, 2014 at 1:11 PM, Junio C Hamano gits...@pobox.com wrote: Ronnie Sahlberg sahlb...@google.com 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 take only atomics when a push tries to update more than one, but this one is iffy. If the receiver accepts non-atomic from older send-pack, those with newer send-pack should have a way to say the receiving end may prefer atomic, but I choose not to. Is there a way to do so? There is no way to do so right now. I can add a --no-atomic-push argument to the client to make it ignore this hint from the server. And if there is such a way, what value does the preference add to the user experience and the server's operation? The reason for this preference was to make it possible to flag a repository to always try to make all pushes atomic, when possible. A preference for convenience. You could set on the server to try to make all pushes atomic so that clients do not have to specify --atomic-push all the time. Currently this is just a hint on from the server and is not enforced for backward compatibility reasons. If the client does not have atomic push support, the client will ignore this hint and just do a normal push instead. This is the least important part in this patch series so I am open for advice : 1, I can remove this patch/preference if you prefer. or 2a, I can add a --no-atomic-push flag to send-pack to have a way to force the client to do a normal nonatomic push even if the server indicates it wants atomic pushes. and/or 2b, I can add another preference receive.requireatomicpush to the server so that the server can reject any push outright if it is not atomic. 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. Please advise. Regards Ronnie Sahlberg -- 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
Re: [PATCH 6/8] receive-pack.c: add a receive.preferatomicpush configuration variable
Ronnie Sahlberg sahlb...@google.com 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 not quite understand why you find that this could be a convenience preference on the server operator's end, that would be my preference, at least until I am convinced why this could be a good idea. Thanks. -- 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
Re: [PATCH 6/8] receive-pack.c: add a receive.preferatomicpush configuration variable
On Thu, Oct 30, 2014 at 3:03 PM, Junio C Hamano gits...@pobox.com wrote: Ronnie Sahlberg sahlb...@google.com 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 not quite understand why you find that this could be a convenience preference on the server operator's end, that would be my preference, at least until I am convinced why this could be a good idea. Thanks. Ok, I dropped this patch. Thanks Ronnie Sahlberg -- 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
