On 09/07/2012 01:09 AM, Junio C Hamano wrote:
> Michael Haggerty <mhag...@alum.mit.edu> writes:
>> Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
> I think I asked why this matters (iow, why it is the right thing to
> do to reject an empty string, instead of treating it as "the current
> directory") in the previous round. I would have expected to find
> the answer be above the S-o-b line here.
The reasons that the change is desirable:
1. The empty string is not a legitimate path according to POSIX; e.g.,
see Linux's path_resolution(7):
In the original UNIX, the empty pathname referred to the current
directory. Nowadays POSIX decrees that an empty pathname
must not be resolved successfully. Linux returns ENOENT in this
Accordingly, comparable standard functions like realpath(3) reject the
2. The functions did not handle the empty path consistently with the way
they handled other paths (namely, the return value contained a trailing
3. This unusual behavior was undocumented.
The above points let me to the conclusion that the anomalous handling of
the empty string was a bug in the implementation rather than an intended
behavior. Moreover, a quick check of callers didn't turn up any that
seemed to rely on the strange behavior.
Do you want a re-roll with this verbiage added to the commit messages of
the two relevant commits?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html