← Back to context

Comment by yes_or_gnome

7 years ago

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

2 comments

yes_or_gnome

Reply
sirmarksalot  7 years ago

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  7 years ago

    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.