Re: [PATCH v10 24/44] fetch.c: use a single ref transaction for all ref updates

[Michael Haggerty <mhagger@alum.mit.edu>]

On 05/17/2014 05:05 PM, Michael Haggerty wrote:
> On 05/16/2014 07:37 PM, Ronnie Sahlberg wrote:
>> [...]
>> disk and thus we would not return STORE_REF_ERROR_DF_CONFLICT for this case.
>>
>> I think this new behaviour is more correct, since if there was a problem
>> we would not even try to commit the transaction but need to highlight this
>> change in how/what errors are reported.
>> This change in what error is returned only occurs if there are multiple
>> refs that fail to update and only some, but not all, of them fail due to
>> ENOTDIR.
> 
> Thanks for the detailed explanation.  The change in behavior seems
> reasonable to me.

Wait, now I'm having second thoughts.

Won't the old code display *all* of the errors that occur, each time
proceeding nevertheless?  Whereas the new code displays only the *first*
error that would occur and then aborts?

This could be very frustrating if three references have problems, but
the user only finds out about one problem each time she runs "git
fetch".  Instead of

    git fetch # oops, ref1, ref2, and ref3 failed
    fix, fix, fix
    git fetch # :-)

she'd have to do

    git fetch # oops, ref1 failed
    fix ref1
    git fetch # oops, ref2 failed
    fix ref2
    git fetch # oops, ref3 failed
    fix ref3
    git fetch # :-( git I hate you

What kind of failures are we talking about here?  Are we talking about
errors like non-ff updates that happen routinely, or rarer/more serious
errors that would be expected to happen singly?

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/