Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

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

 



Louis-Alexandre Stuber <stuberl@xxxxxxxxxxxxxxxxxxxxxxx> writes:

> Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
>
>> I think you would want to error out if errno is not ENOENT.
>
>
> Junio C Hamano <jch2355@xxxxxxxxx> wrote:
>
>> We might want to see why fopen() failed here. If it is because the
>> file did not exist, great. But otherwise?
>
>
> This file is always supposed to exist when the function is called
> unless the user has manually deleted it (or a bug in our programs).
>
> Maybe we should just return an error if the file cannot be opened,
> regardless the reason. We kept it like it is, with the default case,
> because it was what our elders did, and that aborting because of
> BISECT_TERMS is not good for backward compatibility.
>
> But then, in both cases, there is no reason to differenciate ENOENT.
> Is that right ?

One thing that immediately comes to mind is when you (perhaps
accidentally, or perhaps you were asked to) cd into somebody else's
repository and take a look or help, the file exists but cannot be
read by you and you get EPERM.

That is very different from ENOENT, which is an expected error when
you are not using a customized terms.
--
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




[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]