Re: folder naming bug?

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

On Feb 3, 2015, at 12:23 AM, Jeff King [off-list ref] wrote:

On Mon, Feb 02, 2015 at 11:52:21PM -0500, Kevin Coleman wrote:

quoted

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:

quoted

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.

quoted

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.

quoted

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.

quoted

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:

quoted

quoted

quoted

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