Re: [PATCH v9 1/9] git-clean: refactor git-clean into two phases

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

 



Jiang Xin <worldhello.net@xxxxxxxxx> writes:

> 2013/5/15 Junio C Hamano <gitster@xxxxxxxxx>:
>>> @@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
>>>                               continue; /* Yup, this one exists unmerged */
>>>               }
>>>
>>> -             /*
>>> -              * we might have removed this as part of earlier
>>> -              * recursive directory removal, so lstat() here could
>>> -              * fail with ENOENT.
>>> -              */
>>>               if (lstat(ent->name, &st))
>>>                       continue;
>>
>> I am guessing that the reason why you removed the comment is because
>> during this phase there is no way we "might have removed".  But if
>> that is the case, does it still make sense to run lstat() and ignore
>> errors from the call?
>>
>
> Run lstat() here is necessary, because we need to check whether
> ent->name points to a file or a directory. If ent points to a directory,
> only add to del_list when user provides '-x' option to git-clean.

Sorry, but that was not the question; we can see st is used
immediately below so somebody needs to fill it.

I was pointing out that the "lstat() is expected to fail with ENOENT
but it is not an error worth reporting" justification the original
code had to silently ignore an error, because you no longer remove
anything immediately in this part of the code.  Is "if () continue"
still valid thing to do here, not "if () die()"?
--
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]