From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 19 Feb 2016 17:15:11 GMT
Subject: Re: [PATCH 05/20] rename_tmp_log(): use raceproof_create_file()
Message-ID: <xmqq37soei5c.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <56C73DDE.1040606@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

> Now, we have to consider the opposite case, namely that we are calling a
> non-buggy implementation of `rename()`, and we artificially change
> ENOTDIR to EISDIR. Can that cause any bad effects?
>
> I don't think so, because the case where a non-buggy implementation can
> yield ENOTDIR is a case, the consequent call to
> `remove_dir_recursively()` would fail with ENOTDIR too, and
> `raceproof_create_file()` would give up immediately.
>
> So I think everything is OK, though I admit that it is not especially
> elegant.

OK, thanks for a clear analysis.

I knew the original and the update were meant to (and would) behave
the same, but the workaround logic in the original looked iffy.