On Mon, Jan 16, 2012 at 07:50:51PM +0100, Yves Goergen wrote: > It's getting more weird. I believe that (msys)Git doesn't really know > how the filesystem on its operating system works. I have made some more > changes now and want to commit them. TortoiseGit reports the files > Form1.Designer.cs and Form1.designer.cs (note the case difference) as > modified and ready to commit. How is that supposed to work? On Windows, > file names are case-insensitive (as on MacOS X) and both names refer to > the absolute same file. 'git status' has the very same listing with that > same file twice. What is the output of "git config core.ignorecase" in your repository? > If the index is such a problem child, how can I safely delete it > completely and maybe have it regenerated if Git can't live without it? If you delete your index, it will appear to git as if you have staged all files for deletion (if you run "git status", for example). You can then run "git reset" to regenerate it based on the last commit. But I doubt that will help your problem. It seems unlikely to me that the source of the problem is a corrupted index, but rather is some corner case in case-insensitive comparisons between the index and the working tree. -Peff -- 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