Junio C Hamano writes:
> What would be the end-user experience if you stopped at the first
> error? You see an error, add an "fsck. = ignore" and rerun,
> only to find another error and rinse and repeat? Wouldn't you
> rather see all of them and add the "ignore" to cover them in one go?
>
>> I
Johannes Schindelin writes:
>> I do not think this "if (err) return err;" that uses the return
>> value of report(), makes sense.
>>
>> As all the errors that use this pattern are isolated ones that does
>> not break parsing of the remainder (e.g. author ident had an extra >
>> in it may break "
Hi Junio,
On 2015-06-19 22:12, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> Note that some problems are too problematic to simply ignore. For
>> example, when the header lines are mixed up, we punt after encountering
>> an incorrect line. Therefore, demoting certain warnings to error
Johannes Schindelin writes:
> When fsck_commit() identifies a problem with the commit, it should try
> to make it possible to continue checking the commit object, in case the
> user wants to demote the detected errors to mere warnings.
That makes sense.
> Note that some problems are too problem
When fsck_commit() identifies a problem with the commit, it should try
to make it possible to continue checking the commit object, in case the
user wants to demote the detected errors to mere warnings.
Note that some problems are too problematic to simply ignore. For
example, when the header lines
5 matches
Mail list logo