Re: Bug? Git checkout fails with a wrong error message

[Yves Goergen <nospam.list@unclassified.de>]

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@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de