All of lore.kernel.org
 help / color / mirror / Atom feed
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.