Awesome reply! That makes sense. So basically if I accidentally capitalize a folder name and commit it, I need to be very careful when I correct it. Definitely ran into this problem with my repo and ‘lost’ a few commits before I noticed something was off.
-Kevin Coleman
Show 92 quoted lines
> On Feb 3, 2015, at 12:23 AM, Jeff King <peff@peff.net> wrote:
>
> On Mon, Feb 02, 2015 at 11:52:21PM -0500, Kevin Coleman wrote:
>
>> Yes, I am on a Mac. I just tried that, but I don’t think that
>> completely fixed it. As you can see it tracks “foo/bar.md” and then
>> it tracks “Foo/bar.md”. It still tracks both “foo” and “Foo” even tho
>> only “Foo” exists in my dir after the rename.
>
> Yes, because your filesystem _is_ case insensitive, but now you have
> told git that it is not. In your example:
>
>> 11:41:57 ~/test $ git init
>> Initialized empty Git repository in /Users/kcoleman/test/.git/
>> 11:42:03 ~/test (master #) $ git config core.ignorecase false
>> 11:42:06 ~/test (master #) $ mkdir foo
>> 11:42:13 ~/test (master #) $ cd foo
>> 11:42:26 ~/test/foo (master #) $ touch bar.md
>> 11:42:30 ~/test/foo (master #) $ cd ..
>> 11:42:32 ~/test (master #) $ git add .
>
> Now git has "foo" (lowercase) in the index. And that's what your
> filesystem has, too.
>
>> 11:42:35 ~/test (master #) $ git commit -m "first"
>> [master (root-commit) 6125a1d] first
>> 1 file changed, 0 insertions(+), 0 deletions(-)
>> create mode 100644 foo/bar.md
>> 11:42:39 ~/test (master) $ mv foo Foo
>> 11:42:44 ~/test (master) $ ls
>> Foo
>
> Now we still have "foo" in the index, but "Foo" in the filesystem.
>
>> 11:42:46 ~/test (master) $ git status
>> On branch master
>> Untracked files:
>> (use "git add <file>..." to include in what will be committed)
>>
>> Foo/
>
> When git asks the filesystem lstat("foo") to find out if we still have
> it, the filesystem returns the entry for "Foo" (because it is
> case-insensitive).
>
> But when git asks the filesystem to iterate over all of the files, so it
> can check which ones are not tracked, it will get "Foo", which of course
> is not in the index.
>
> So you do not see a deletion of "foo", but you do see "Foo" as
> untracked.
>
>> 11:42:48 ~/test (master) $ git add .
>> 11:43:18 ~/test (master +) $ git commit -m "second"
>> [master f78d025] second
>> 1 file changed, 0 insertions(+), 0 deletions(-)
>> create mode 100644 Foo/bar.md
>
> And this tells git to look through the filesystem for untracked files
> and add them to the index. So it adds "Foo".
>
> Now that you have both "foo" and "Foo" in the index, but the filesystem
> treats them the same, you can create more mayhem. If you were to update
> one entry but not the other (e.g., by writing to bar.md before doing the
> second commit), then git would be perpetually confused. _One_ of the
> files would always look like needed to be updated, because the
> filesystem cannot represent the situation that is in the index.
>
> And that is why git sets core.ignorecase in the first place. :)
>
> As to your original problem:
>
>>>> git isn’t tracking folder renames when the case of the letters
>>>> change, but it will track it if the folder changes names. Is this
>>>> intentional?
>
> Yes, this is intentional. Your filesystem treats them as the same file,
> so git has to, as well.
>
> If your goal is to change the case that git records, then you should be
> able to do it with "git mv". But git will never pick up a case change
> that you made separately in the filesystem, because it's
> indistinguishable from the filesystem simply picking a different case to
> store the file.
>
> And that does happen. For instance, if you switch between two branches
> with "Foo" and "foo", most case-preserving filesystems will leave you
> with whichever version you had first (i.e., git asks the filesystem to
> open "foo", and the filesystem says "ah, I already have Foo; that must
> have been what you meant").
>
> -Peff