threads / discuss / 10475

Trouble with case-insensitive filesystems

Subject: Trouble with case-insensitive filesystems

## tl;dr

5 messages between Oct 26, 2007 and Oct 26, 2007.

replies: 4people: 4as markdown or json

Rocco Rutte· Oct 26, 2007, 14:52 UTC · lore

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

Andreas Ericsson· Oct 26, 2007, 15:22 UTC · re: Rocco Rutte · lore

Re: Trouble with case-insensitive filesystems

Rocco Rutte wrote:

Show 35 quoted lines

> 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

Rocco Rutte· Oct 26, 2007, 16:11 UTC · re: Andreas Ericsson · lore

Re: Trouble with case-insensitive filesystems

Hi,

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

Show 7 quoted lines

> 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

Jeff King· Oct 26, 2007, 16:34 UTC · re: Andreas Ericsson · lore

Re: Trouble with case-insensitive filesystems

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

Jean-François Veillette· Oct 26, 2007, 15:29 UTC · re: Rocco Rutte · lore

Re: Trouble with case-insensitive filesystems

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 :

Show 44 quoted lines

> 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