git/list[1] front-page[2] threads[3] people[4] search[5] about
 

ignorecase interoperability bugs

From
Joey Hess <joey@kitenet.net>
Date
Mar 31, 2011, 19:18 UTC
Message-ID
<20110331191836.GA16342@gnu.kitenet.net>

Suppose I have two clones of a repo. "mac" has ignorecase=true and is on HFS+, and "lin" has ignorecase=false and is on ext4. With git 1.7.4, I have found some very unusual behavior.

on mac (omitting all git output to save space):

$ mkdir X $ echo mac > X/foo $ git add X/foo $ git commit -m "added X/foo"

on lin (omitting all git output to save space):

$ git pull mac master # now X/foo exists here $ mkdir x $ echo lin > x/foo $ git add x/foo $ git commit -m "added x/foo"

on mac:
$ git pull lin master
[...]
 * branch            master     -> FETCH_HEAD
Updating a3dbf10..2d4223d
Fast-forward
 x/foo |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 x/foo
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   X/foo
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git add X/foo
$ git commit X
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   X/foo
#
no changes added to commit (use "git add" and/or "git commit -a")

So, it's possible to get files that git thinks are changed, but cannot be committed.

$ echo testing > X/foo $ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: X/foo # modified: x/foo

And it's possible to have multiple cases of the same file show up even though ignorecase=true.

The problems don't end there. Suppose I have a program that expects to find a file in proggy/config. But, on mac, I already have a Proggy/Data file that I created & committed for some reason. No problem; I write my config to proggy/config; the program can read its file, I commit proggy/config, and all seems well. Now I clone to lin, and see:

$ ls Proggy/Data Proggy/config $ proggy proggy: cannot open proggy/config: file does not exist

Git 1.7.2.5 seems to handle both these cases better; the ignorecase rework in 1.7.4 introduced most of these problems AFAICS.

-- 
see shy jo
Message 1 of 1 in “ignorecase interoperability bugs”
  1. Joey HessMar 31, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.