Trouble with case-insensitive filesystems

Trouble with case-insensitive filesystems

[Rocco Rutte]

Hi,

after importing the opensolaris hg repo into git, I noticed that git 
gets confused if the repo contains files that clash on case-insensitive 
filesystems (here on OS X, I can't test Cygwin and Win32). git-checkout 
tells me that these files are modified, git-status gives me:

$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HB
#       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HB.name
#       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HI
#       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HI.name
#       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HX
#       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HX.name
#       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/charlib/LH
#       modified:   usr/src/lib/libldap4/common/Version.c
#
no changes added to commit (use "git add" and/or "git commit -a")

...without touching anything. Yes, there's a version.c file next to 
Version.c, HI.name next to Hi.name and so on.

I'm not really sure what I'm expecting git to do, but I guess I want it 
to abort a checkout and only continue with -f. But at the very least, it 
should issue a big fat warning (one may decide to work in some area 
without clashes).

I really have no idea how to efficiently detect that at runtime and 
which areas of git to look at for patching...

Rocco

Re: Trouble with case-insensitive filesystems

[Andreas Ericsson]

Rocco Rutte wrote:
> Hi,
> 
> after importing the opensolaris hg repo into git, I noticed that git 
> gets confused if the repo contains files that clash on case-insensitive 
> filesystems (here on OS X, I can't test Cygwin and Win32). git-checkout 
> tells me that these files are modified, git-status gives me:
> 
> $ git status
> # On branch master
> # Changed but not updated:
> #   (use "git add <file>..." to update what will be committed)
> #
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HB
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HB.name
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HI
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HI.name
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HX
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HX.name
> #       modified:   
> usr/src/cmd/lp/filter/postscript/font/devpost/charlib/LH
> #       modified:   usr/src/lib/libldap4/common/Version.c
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> 
> ...without touching anything. Yes, there's a version.c file next to 
> Version.c, HI.name next to Hi.name and so on.
> 
> I'm not really sure what I'm expecting git to do, but I guess I want it 
> to abort a checkout and only continue with -f. But at the very least, it 
> should issue a big fat warning (one may decide to work in some area 
> without clashes).
> 
> I really have no idea how to efficiently detect that at runtime and 
> which areas of git to look at for patching...
> 

There are no areas in git to patch. There's no sane way to handle your
case, so the best you could opt for is to import it to a system with
sane case-handling, alter the repo so no two filenames clash, and then
check it out on your case-insensitive filesystem. Note that you'll
have to make sure that you never check anything out prior to the
commit that renames the case-name clashes, or you'll end up with this
same trouble all over again.

On a side note; Please don't set the Reply-To: header for mails to
git@vger.kernel.org. Some consider it rude, and it makes the ones
you're asking for help have to work if they want to provide you
with anything off-list. It's a tad rude.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Trouble with case-insensitive filesystems

[Rocco Rutte]

Hi,

* Andreas Ericsson [07-10-26 17:22:52 +0200] wrote:

> There are no areas in git to patch. There's no sane way to handle your
> case, so the best you could opt for is to import it to a system with
> sane case-handling, alter the repo so no two filenames clash, and then
> check it out on your case-insensitive filesystem. Note that you'll
> have to make sure that you never check anything out prior to the
> commit that renames the case-name clashes, or you'll end up with this
> same trouble all over again.

Personally I don't have a problem with that (since I do no work with 
that repo). But IMHO it's bad to leave people without a clue what could 
be wrong when git-status right after git-checkout/git-clone reports 
changes. Btw, mercurial reports the problem so immediately know what's 
wrong.

> On a side note; Please don't set the Reply-To: header for mails to
> git@vger.kernel.org. Some consider it rude, and it makes the ones
> you're asking for help have to work if they want to provide you
> with anything off-list. It's a tad rude.

I didn't set a Reply-To: header, just Mail-Followup-To: which is exactly 
what I want (in mutt language): Private mails via reply only go to me 
and list-reply goes to the list.

Rocco

Re: Trouble with case-insensitive filesystems

[Jeff King]

On Fri, Oct 26, 2007 at 05:22:52PM +0200, Andreas Ericsson wrote:

> There are no areas in git to patch. There's no sane way to handle your
> case, so the best you could opt for is to import it to a system with
> sane case-handling, alter the repo so no two filenames clash, and then
> check it out on your case-insensitive filesystem. Note that you'll

You don't need a sane system, since git's index provides one:

  # make our new repo without checking anything out
  git-clone -n /path/to/other/repo repo
  cd repo

  # grab a text representation of what would be checked out
  git-ls-tree -r HEAD >files
  # fix up any broken filenames
  $EDITOR files
  # and shove it into the index
  git-update-index --index-info <files

  # update your working tree
  git-checkout-index -a
  # and optionally save the commit
  git-commit -m 'broken filenames hack'

Of course, all of the prior commits won't be usable. You would have to
repeat this hack on every commit using git-filter-branch for that.

-Peff

Re: Trouble with case-insensitive filesystems

[Jean-François Veillette]

You can workaround this by creating a disk-image with a case- 
sensitive filesystem, then do your work inside that virtual drive.

- jfv

Le 07-10-26 à 10:52, Rocco Rutte a écrit :

> Hi,
>
> after importing the opensolaris hg repo into git, I noticed that  
> git gets confused if the repo contains files that clash on case- 
> insensitive filesystems (here on OS X, I can't test Cygwin and  
> Win32). git-checkout tells me that these files are modified, git- 
> status gives me:
>
> $ git status
> # On branch master
> # Changed but not updated:
> #   (use "git add <file>..." to update what will be committed)
> #
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HB
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/ 
> HB.name
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HI
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/ 
> HI.name
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/HX
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/ 
> HX.name
> #       modified:   usr/src/cmd/lp/filter/postscript/font/devpost/ 
> charlib/LH
> #       modified:   usr/src/lib/libldap4/common/Version.c
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> ...without touching anything. Yes, there's a version.c file next to  
> Version.c, HI.name next to Hi.name and so on.
>
> I'm not really sure what I'm expecting git to do, but I guess I  
> want it to abort a checkout and only continue with -f. But at the  
> very least, it should issue a big fat warning (one may decide to  
> work in some area without clashes).
>
> I really have no idea how to efficiently detect that at runtime and  
> which areas of git to look at for patching...
>
> Rocco
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html