Am 26.01.2011 00:31, schrieb Erik Faye-Lund: > On Wed, Jan 26, 2011 at 12:26 AM, Simeon Maxein <smaxein@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html