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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).