Re: [PATCH v10 24/44] fetch.c: use a single ref transaction for all ref updates
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- May 17, 2014, 15:17 UTC
- Message-ID
- <53777D89.2090501@alum.mit.edu>
- In-Reply-To
- <53777AA1.1020107@alum.mit.edu>
On 05/17/2014 05:05 PM, Michael Haggerty wrote:
Show 13 quoted lines
> 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 youWhat 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/