[yes_or_gnome]

Not really an issue with git, but with OSX. In doing some research of git, I wanted to look at the first git repos. Those are torvalds/git.git and torvalds/linux.git. If you clone linux.git on OSX and run `git status`, you'll see this:

    $ git status --short
    ## master...origin/master
    M include/uapi/linux/netfilter/xt_connmark.h
    M include/uapi/linux/netfilter/xt_dscp.h
    M include/uapi/linux/netfilter/xt_mark.h
    M include/uapi/linux/netfilter/xt_rateest.h
    M include/uapi/linux/netfilter/xt_tcpmss.h
    M include/uapi/linux/netfilter_ipv4/ipt_ecn.h
    M include/uapi/linux/netfilter_ipv4/ipt_ttl.h
    M include/uapi/linux/netfilter_ipv6/ip6t_hl.h
    M net/netfilter/xt_dscp.c
    M net/netfilter/xt_hl.c
    M net/netfilter/xt_rateest.c
    M net/netfilter/xt_tcpmss.c

[sirmarksalot]

I disagree here. Case-insensitive file systems have existed for decades, and are part of the development landscape. Any tool that works across multiple machines needs to support them. In this case, I blame Bitbucket, for not providing any way to treat this as a merge conflict.

[yes_or_gnome]

The tool that doesn't work with case insensitive filenames is OSX.

Edit: To add, how is git supposed to handle two files with the same name -- as is the case -- with a case insensitive file system? You can't have two files with the "same" name.

    git checkout file1

Is entirely different than

    git checkout FILE1

In any other platform ls file1 FILE1 would show two different files, but on OSX, it'll show the same file twice.