CODEWITHSUNDEEP
gitmacoscase-insensitive
Daniel Griscom
Daniel Griscom

Reputation: 2263

Git on OS X: pre-modified files?

I'm using Git on OS X, specifically the humongous Linux repository. Problem: when I check out a specific branch, when I expect to have a clean directory tree, I'll find that there are already modified files:

mbpe:linux griscom$ git checkout --force 6407198
HEAD is now at 6407198... sdhci: add no-sd-uhs-sdr104 devicetree property
mbpe:linux griscom$ git status
HEAD detached at 6407198
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:   include/uapi/linux/netfilter/xt_connmark.h
    modified:   include/uapi/linux/netfilter/xt_dscp.h
    modified:   include/uapi/linux/netfilter/xt_mark.h
    modified:   include/uapi/linux/netfilter/xt_rateest.h
    modified:   include/uapi/linux/netfilter/xt_tcpmss.h
    modified:   include/uapi/linux/netfilter_ipv4/ipt_ecn.h
    modified:   include/uapi/linux/netfilter_ipv4/ipt_ttl.h
    modified:   include/uapi/linux/netfilter_ipv6/ip6t_hl.h
    modified:   net/netfilter/xt_dscp.c
    modified:   net/netfilter/xt_hl.c
    modified:   net/netfilter/xt_rateest.c
    modified:   net/netfilter/xt_tcpmss.c

no changes added to commit (use "git add" and/or "git commit -a")
mbpe:linux griscom$

Here's the really fun part: if I try to get rid of these "modified" files, I get a new set of modified files with some of the character cases changed:

mbpe:linux griscom$ git reset --hard
HEAD is now at 6407198 sdhci: add no-sd-uhs-sdr104 devicetree property
mbpe:linux griscom$ git status
HEAD detached at 6407198
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:   include/uapi/linux/netfilter/xt_CONNMARK.h
    modified:   include/uapi/linux/netfilter/xt_DSCP.h
    modified:   include/uapi/linux/netfilter/xt_MARK.h
    modified:   include/uapi/linux/netfilter/xt_RATEEST.h
    modified:   include/uapi/linux/netfilter/xt_TCPMSS.h
    modified:   include/uapi/linux/netfilter_ipv4/ipt_ECN.h
    modified:   include/uapi/linux/netfilter_ipv4/ipt_TTL.h
    modified:   include/uapi/linux/netfilter_ipv6/ip6t_HL.h
    modified:   net/netfilter/xt_DSCP.c
    modified:   net/netfilter/xt_HL.c
    modified:   net/netfilter/xt_RATEEST.c
    modified:   net/netfilter/xt_TCPMSS.c

no changes added to commit (use "git add" and/or "git commit -a")
mbpe:linux griscom$

What the heck is going on???

Upvotes: 0

Views: 130

Answers (1)

Daniel Griscom
Daniel Griscom

Reputation: 2263

The answer: the default OS X file system is case-insensitive (although case-preserving), and the Linux repository has a number of pairs of files which only differ by case. In fact, the above two lists of files are exactly the pairs of case-conflicting files in the repository.

So, where git thinks there are two files, the OS X file system thinks there is only one. In the process of checking all the files out, the two files are written on top of each other, and when checking for changes git treats this as a change in one of each pair of files. While resetting the repository, the "modified" file of each pair is unmodified, but this inevitably modifies the previously-"unmodified" one.

Which brings up a couple of academic questions:

  • Why doesn't git, which could easily detect this problem, give an intelligent error message?
  • Who thought it would be a good idea to have files in the Linux repository that differed only by case?

Upvotes: 1

Related Questions