Re: [PATCH 1/2] init-db.c: honor case on case preserving fs

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Feb 1, 2014, 23:47 UTC
Message-ID: <CAHkcotgdEKkZZ756LHxD0fum0_z43cerQE_yZR0VSnPZOKtKpA@mail.gmail.com>
In-Reply-To: <CAD_8n+RWNZkGO31XveDuSy2aXv5uAMy087AUUu2+wXtO=MngAg@mail.gmail.com>

On Sat, Feb 1, 2014 at 1:14 PM, Reuben Hawkins <reubenhwk@gmail.com> wrote:

Show 6 quoted lines

> Most case-insensitive filesystems are case-preserving. In these
> filesystems (such as HFS+ on OS X) you can name a file Filename.txt,
> then rename the file to FileName.txt.  That file will be accessible
> by both filenames, but the case is otherwise honored.  We don't want
> to have git ignore case on these case-preserving filesystem
> implementations.

Actually, we want to ignore case on ANY case-insensitive file system whether it is a case-preserving or not.

Let's suppose we have a central repository where Filename.txt is renamed as FileName.txt. Now a user pulls changes from that repository on Windows.

With core.ignorecase = true, everything works perfectly:

$ git pull
remote: Counting objects: 3, done.
remote: Total 2 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
From z:/shared/test2/
   3d885e6..ce5deef  master     -> origin/master
Updating 3d885e6..ce5deef
Fast-forward
 Filename.txt => FileName.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename Filename.txt => FileName.txt (100%)

$ ls FileName.txt

Now, if you try to do the same thing with core.ignorecase = false, you get this:

$ git pull
remote: Counting objects: 3, done.
remote: Total 2 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
From z:/shared/test2/
   3d885e6..ce5deef  master     -> origin/master
Updating 3d885e6..ce5deef
error: The following untracked working tree files would be overwritten by merge:
        FileName.txt
Please move or remove them before you can merge.
Aborting

I have tested this with git version 1.8.3.msysgit.0, but I don't think it is any different with the latest version.

> This fixes a problem where if you import an hg repository, using
> git-remote-hg,

Perhaps, it fixes that case, but it breaks a far more common case. So I believe that git-remote-hg should be corrected and not init-db.c

Dmitry