Because the 'executability' of a file is a property of the file entry on UNIX systems, not of the file type like it is on Windows.
ls will list a file as being executable if any of the owner, group, or everyone has execute permissions for the file. It doesn't care what the file type is, just what the permissions are. This behavior gives two significant benefits:
- You don't have to do anything special to handle new executable formats. This is particularly useful for scripting languages, where you can just embed the interpreter with a
#! line at the top of the file. The kernel doesn't have to know that
.py files are executable, because the permissions tell it this. This also, when combined with
binfmt_misc support on Linux, makes it possible to do really neat things such as treating Windows console programs like native binaries if you have Wine installed.
- It lets you say that certain files that are technically machine code can't or shouldn't be executed. This is also mostly used with scripting languages, where it's not unusual to have libraries that are indistinguishable in terms of file format form executables. So, using the python example above, it lets you say that people shouldnt' be able to run arbitrary modules form the Python standard library directly, even though they have a
However, this all kind of falls apart if you're stuck dealing with filesystems that don't support POSIX permissions, such as FAT (or NTFS if you don't have user-mappings set up). If the filesystem doesn't store POSIX permissions, then the OS has to simulate them. On Linux the default is to have read write and execute permissions set for everyone, so that users can just do what they want with the files. Without this, you wouldn't be able to execute scripts or binaries off of a USB flash drive, because the kernel doesn't let you modify permissions on such filesystems per-file.
In your particular case,
git stores the attributes it sees on the files when they are committed, and the original commit of the README.md file (or one of the subsequent commits to it) probably happened on a Windows system, where such things are handled very differently, and thus
git just stores the permissions as full access for everyone, similarly to how Linux handles fiesystems without permissions support.