Re: [PATCH v6 12/19] fsck: Disallow demoting grave fsck errors to warnings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ahh, I didn't see that they were not grouped by object types, features
or any meaningful axis.
That explains it (i.e. I can now understand why the original list was
ordered differently from the final order).


On Fri, Jun 19, 2015 at 2:09 PM, Johannes Schindelin
<johannes.schindelin@xxxxxx> wrote:
> Hi Junio,
>
> On 2015-06-19 22:21, Junio C Hamano wrote:
>> Johannes Schindelin <johannes.schindelin@xxxxxx> writes:
>>
>>> Some kinds of errors are intrinsically unrecoverable (e.g. errors while
>>> uncompressing objects). It does not make sense to allow demoting them to
>>> mere warnings.
>>>
>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
>>> ---
>>>  fsck.c                          | 14 ++++++++++++--
>>>  t/t5504-fetch-receive-strict.sh | 11 +++++++++++
>>>  2 files changed, 23 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fsck.c b/fsck.c
>>> index 21e3052..a4fbce3 100644
>>> --- a/fsck.c
>>> +++ b/fsck.c
>>> @@ -9,7 +9,12 @@
>>>  #include "refs.h"
>>>  #include "utf8.h"
>>>
>>> +#define FSCK_FATAL -1
>>> +
>>>  #define FOREACH_MSG_ID(FUNC) \
>>> +    /* fatal errors */ \
>>> +    FUNC(NUL_IN_HEADER, FATAL) \
>>> +    FUNC(UNTERMINATED_HEADER, FATAL) \
>>>      /* errors */ \
>>>      FUNC(BAD_DATE, ERROR) \
>>>      FUNC(BAD_DATE_OVERFLOW, ERROR) \
>>> @@ -39,11 +44,9 @@
>>>      FUNC(MISSING_TYPE, ERROR) \
>>>      FUNC(MISSING_TYPE_ENTRY, ERROR) \
>>>      FUNC(MULTIPLE_AUTHORS, ERROR) \
>>> -    FUNC(NUL_IN_HEADER, ERROR) \
>>>      FUNC(TAG_OBJECT_NOT_TAG, ERROR) \
>>>      FUNC(TREE_NOT_SORTED, ERROR) \
>>>      FUNC(UNKNOWN_TYPE, ERROR) \
>>> -    FUNC(UNTERMINATED_HEADER, ERROR) \
>>
>> I think the end result very much makes a good sense, but why didn't
>> this list enumerate the errors in the above "final" order from the
>> beginning in 02/19?
>
> Because they are alphabetically ordered, within message type categories, that is; this helped me develop with more ease (you do not want to know how many hundreds of times I ran an interactive rebase on all of these patches...).
>
> And from the point of a development story (which a patch series is), it would puzzle me, as a reader, if those two out of all the others were in front in 02/19, when they are no different from the others at that stage.
>
> Ciao,
> Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]