On 17.01.2012 09:45 CE(S)T, Thomas Rast wrote: > It would also be interesting to know for how long this problem has > existed. You can search for the offending commit with something like > > git log --name-status --diff-filter=A -- "PosterWantsItCensored.*" > > which should normally give you just one or two commits, namely the > one(s) that introduced the two files. I have found two commits adding that file. The second one has the file with the then-already-present name modified and the new spelling added. I could have noticed that at commit time, but that's the very commit where I also renamed the original files and recreated them in the Forms designer. 1) This may have led me to overlook that additional add and 2) this may be the source of the spelling difference because the file was newly created. > As for the fix, there are two-and-two-thirds cases. (...) That all sounds quite complicated. The "offending" commit is quite a while back so replacing the last commit is not a solution. This is just my personal repository that should help me out with finding changes when I find something broken that wasn't before. Deleting and recreating the "hub" (bare) and the other working repository would be okay for me in this case. I have decided that it is also okay to fix the error by new commits. To avoid all further issues with this, I have renamed the file, committed the deletion, renamed it back and then committed the add. The revsion in between won't compile, but it's got a message with it and the compiler error would be obvious. > You should really read up on this, e.g. > > http://tomayko.com/writings/the-thing-about-git > > AFAIK everyone who groks the feature uses it daily. It's on my to-read list. Looks like an interesting article from reading the beginning of it. I have done a test, too: I have set the core.ignorecase setting to false (or deleted its entry) and then renamed one of the files in my working directory only in case. TortoiseGit has offered me adding the new spelling for a commit. After setting the core.ignorecase setting to true, it has not offered any change to commit anymore. So it looks like this is just the setting that every repository for Windows use should - no - must have, and it was missing here. Just like that stupid autocrlf that causes more issues than it solves. I regularly see files with all lines changed and the diff says that both files only differ in line endings. But I have no sure observation on whether that value was set or unset in those cases. I'll have to look after that, too. These two config settings are not cloned with the repository, are they? Also, TortoiseGit already sets ignorecase = true. So maybe the Visual Studio provider does the init on its own and is missing that. Or I have at some time cloned the repository and the setting wasn't copied over. -- Yves Goergen "LonelyPixel" <nospam.list@xxxxxxxxxxxxxxx> Visit my web laboratory at http://beta.unclassified.de -- 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