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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html