Re: [PATCHv2 4/6] receive-pack.c: use a single ref_transaction for atomic pushes

2014-12-16 Thread Eric Sunshine
On Tue, Dec 16, 2014 at 2:29 PM, Eric Sunshine wrote: > On Tue, Dec 16, 2014 at 1:49 PM, Stefan Beller wrote: >> --- >> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c >> index e76e5d5..0803fd2 100644 >> --- a/builtin/receive-pack.c >> +++ b/builtin/receive-pack.c >> @@ -1059,6 +1059

Re: [PATCHv2 4/6] receive-pack.c: use a single ref_transaction for atomic pushes

2014-12-16 Thread Junio C Hamano
Stefan Beller writes: > * update(...) assumes to be always in a transaction > * Caring about when to begin/commit transactions is put > into execute_commands I am obviously biased, but I find that the new code structure and separation of responsibility between update() and ex

Re: [PATCHv2 4/6] receive-pack.c: use a single ref_transaction for atomic pushes

2014-12-16 Thread Eric Sunshine
On Tue, Dec 16, 2014 at 1:49 PM, Stefan Beller wrote: > From: Ronnie Sahlberg > > Update receive-pack to use an atomic transaction iff the client negotiated > that it wanted atomic-push. This leaves the default behavior to be the old > non-atomic one ref at a time update. This is to cause as litt

[PATCHv2 4/6] receive-pack.c: use a single ref_transaction for atomic pushes

2014-12-16 Thread Stefan Beller
From: Ronnie Sahlberg Update receive-pack to use an atomic transaction iff the client negotiated that it wanted atomic-push. This leaves the default behavior to be the old non-atomic one ref at a time update. This is to cause as little disruption as possible to existing clients. It is unknown if