Re: [PATCH] repository: pre-initialize hash algo pointer

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jan 20, 2018, 09:38 UTC
Message-ID: <CAPig+cR08-EsBGkrGckG5zTN3iPeLL4cj1g5TykicQJe7sK-pQ@mail.gmail.com>
In-Reply-To: <xmqqo9lpnhdb.fsf@gitster.mtv.corp.google.com>

On Sat, Jan 20, 2018 at 2:01 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 19 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>> Now that we know (due to Duy's excellent detective work[1]) that the
>>> trigger is files with names differing only in case on case-insensitive
>>> filesystems, the commit message can be updated appropriately.
>>
>> Thanks.  Let me apply the following and do a 2.16.1, hopefully by
>> the end of day or mid tomorrow at the latest.  Test to protect the
>> fix can come as a separate follow-up patch.
>
> I actually changed my mind and decided not to rush 2.16.1 with just
> this change.  After all, even though it is better not to crash in
> such a problematic case, a "successful" clone of such a project on
> such a filesystem cannot be sanely used *anyway*, so in that sense
> the "fix" would stop "clone" from segfaulting but the resulting
> repository would still be "wrong" (e.g. "git status" immediately
> after clone would likely to say that the working tree is already
> dirty and missing one of the two paths, or something silly like
> that).

The counter-argument is that filenames differing only in case do not necessarily render a project unusable on case-insensitive filesystems. For instance, if the problematic files exist only in a project's test suite or in some platform-specific resource directory, the project itself may still be perfectly usable for a person cloning a project merely to build and use it (not develop it). However, "clone" crashing _does_ render the project unusable for the same person.

The crash[1] when cloning 'tcell' is an example of a project which is still 100% usable on case-insensitive filesystems despite case-conflicting filenames. Each of the conflicting file pairs [2] has identical content, so everything works as intended.

Case-conflicting filenames also do not necessarily make it impossible to do development work on a project. I have, myself, on several occasions cloned such projects on MacOS to make improvements and track down and/or fix bugs in parts of the projects not impacted by the case-conflicting filenames.

Footnotes:

[1]: https://public-inbox.org/git/20180119180855.GA98561@smm.local/

[2]: case-conflicting files in tcell's bundled terminfo database:
    terminfo/database/32/2621A
    terminfo/database/32/2621a
    terminfo/database/68/hp2621A
    terminfo/database/68/hp2621a
    terminfo/database/68/hp70092A
    terminfo/database/68/hp70092a