Re: git filter-branch can "forget" directories on case insensitive filesystems
- From
Simeon Maxein <smaxein@googlemail.com>
- Date
- Jan 26, 2011, 00:24 UTC
- Message-ID
- <4D3F69D2.800@googlemail.com>
- In-Reply-To
- <AANLkTimvwNs9EkV1GweT7VCdzvcz5J5_0pCUA44urQYH@mail.gmail.com>
Am 26.01.2011 00:31, schrieb Erik Faye-Lund:
Show 30 quoted lines
> 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