Re: [PATCH] ls-files: do not trust stat info if lstat() fails
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 3, 2014, 16:30 UTC
- Message-ID
- <xmqqvbuqqstn.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <CACsJy8DBixHTeqitcAcQRAqY3b4prkwQGgJGuw7hbT7BQAZt9w@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
Show 19 quoted lines
> On Thu, Apr 3, 2014 at 1:15 AM, Junio C Hamano <gitster@pobox.com> wrote: >> I am guessing that, even though this was discovered during the >> development of list-files, is a fix applicable outside the context >> of that series. >> >> I do think the patched result is an improvement than the status quo, >> but at the same time, I find it insufficient in the context of the >> whole codepath. What if errno were other than ENOENT and we were >> told to show_deleted (with or without show_modified)? We would end >> up saying the path was deleted and modified at the same time, when >> we do not know either is or is not true at all, because of the >> failure to lstat() the path. >> >> Wouldn't it be saner to add tag_unknown and do something like this >> instead, I wonder? > > Or even better to show an error message when the error code is > unexpected? The unkown tag '!' says "there are problems" but if it > shows up sort of permanently, '!' won't help much, I think.
I am OK with that approach, but then one question remains: should we say it is deleted, modified, both, or neither?