Re: [PATCH] fast-import: add options to enable/disable case folding

[Junio C Hamano <gitster@pobox.com>]

Torsten Bögershausen <tboegi@web.de> writes:

>> +--[no-]fold-case::
>> +	When files/directories with the same name but a different case
>> +	are detected, they are treated as the same (--fold-case) or as
>> +	being different (--no-fold-case). The default is --fold-case
>> +	when `core.ignorecase` is set to `true`, and --no-fold-case when
>> +	it is `false`.
>> +
> Most often the we use the term "ignore-case", could that be a better name ?
> Other opinions, pros/cons  ?

Yeah, --[no-]ignore-case sounds more in line with how other
commands' options are spelled.

But I somehow thought this "case-folding" was deliberately done as
an improvement against the original that did not have a way to do
the "ignore-case"?

http://thread.gmane.org/gmane.comp.version-control.git/200597/focus=200625

I am not sure why not until now I did not find the original
justification dubious, but I think fast-export should never do case
folding---Joshua talks about working trees on a file system that is
incapable of expressing different cases, but "export" is about
reading in-repository histories, whose trees are fully capable of
expressing paths in different cases just fine, and spitting out a
file that can be processed by fast-import.  I do not see why it
should collapse two different paths that differ in case at export
time.

If the original history is broken by Perforce or whatever and
recording the history of the same path in different case
combinations in different commits, perhaps the right thing to do is
to fix the original history in Git repository before exporting in
the first place.

I do not see how such a corruption is related to the characteristics
of the filesystem where "export" is run.  Perhaps a case-insensitive
filesystem may helped Perforce to corrupt the history when initial
import of the history into Git was done, but core.ignorecase of the
current repository does not help us decide if that was actually the
case---the import may have been done on a completely different
machine.

So perhaps we should rip the case folding out altogether instead?
The entry for the change in the Release Notes may say:

 * "git fast-import" incorrectly case-folded the paths recorded in
   the history when core.ignorease is set (i.e. the repository's
   working tree is incapable of expressing paths that differ only in
   their cases); this old bug was reported in 2012 and was finally
   corrected.

or something like that?