From: Joey Hess <joey@kitenet.net>
To: git@vger.kernel.org
Subject: ignorecase interoperability bugs
Date: Thu, 31 Mar 2011 15:18:36 -0400 [thread overview]
Message-ID: <20110331191836.GA16342@gnu.kitenet.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
reply other threads:[~2011-03-31 19:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110331191836.GA16342@gnu.kitenet.net \
--to=joey@kitenet.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.