Re: git filter-branch can "forget" directories on case insensitive filesystems

[Simeon Maxein <smaxein@googlemail.com>]

Am 26.01.2011 00:31, schrieb Erik Faye-Lund:
> On Wed, Jan 26, 2011 at 12:26 AM, Simeon Maxein <smaxein@googlemail.com> wrote:
>> Am 25.01.2011 22:56, schrieb Johannes Sixt:
>>> On Dienstag, 25. Januar 2011, Simeon Maxein wrote:
>>>> In my opinion this is a quite serious issue, because files are lost
>>>> without any indication to the user. As of git 1.7.3.1 (tested on
>>>> Windows/NTFS with msysGit this time), the problem still exists. Please
>>>> give it a look. Fullquote of the problem description / steps to
>>>> reproduce follows.
>>>>> mkdir testdir
>>>>> echo 'abc' >testdir/testfile
>>>>> git add testdir
>>>>> git commit -m foo
>>>>> git rm -r testdir
>>>>> mkdir testDir
>>>>> echo 'abc' >testDir/testfile
>>>>> git add testDir
>>>>> git commit -m bar
>>> Please retry with current release condidate of 1.7.4; it has some
>>> core.ignorecase improvements w.r.t. directories. It could well be that your
>>> problem is fixed.
>>>
>>> -- Hannes
>> Thanks for the suggestion. The directory doesn't vanish anymore with
>> 1.7.4, so a big Thank You to the developers for improving this. When
>> rewriting the second commit ls still prints testdir as lowercase though.
>> More of a nitpick, but it would still be neat to have it right.
>>
> This part is correct behavior  - git's internal representation is case
> sensitive. So git's record of the file is still 'testdir', even i
> you've deleted it and created a new called 'testDir'.
A normal checkout for those commits results in "testdir" for the first
one and "testDir" for the second one, so git does store the name
difference. I would intuitively expect the trees prepared during
filter-branch to be consistent with the result of a checkout.

Simeon