Linux Kernel sources modified on OSX right after clone

Question

When I clone Linux sources on an OS X, they immediately get changed, and git reset --hard doesn't bring the contents back. Here's a full session:

$ git clone git://github.com/torvalds/linux.git
$ cd linux
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
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")

As we can see, the files changed right after cloning. And not even their metadata, but contents:

git diff include/uapi/linux/netfilter_ipv6/ip6t_HL.h
index ebd8ead..6e76dbc 100644
--- a/include/uapi/linux/netfilter_ipv6/ip6t_HL.h
+++ b/include/uapi/linux/netfilter_ipv6/ip6t_HL.h
@@ -1,6 +1,6 @@
-/* Hop Limit modification module for ip6tables
+/* ip6tables module for matching the Hop Limit value
  * Maciej Soltysiak <solt@dns.toxicfilms.tv>
- * Based on HW's TTL module */
+ * Based on HW's ttl module */

 #ifndef _IP6T_HL_H
 #define _IP6T_HL_H
@@ -8,14 +8,14 @@
 #include <linux/types.h>

 enum {
-   IP6T_HL_SET = 0,
-   IP6T_HL_INC,
-   IP6T_HL_DEC
+   IP6T_HL_EQ = 0,     /* equals */
+   IP6T_HL_NE,     /* not equals */
+   IP6T_HL_LT,     /* less than */
+   IP6T_HL_GT,     /* greater than */
 };

-#define IP6T_HL_MAXMODE    IP6T_HL_DEC

-struct ip6t_HL_info {
+struct ip6t_hl_info {
    __u8    mode;
    __u8    hop_limit;
 };

System information:

File system: Journaled HFS+
Operating System: OS X 10.11.5 (15F34)
git version: 2.9.0
~/.gitconfig has only [user] entry.

What is going on? Why are the files modified right after cloning?

Maybe because there are multiple similarly named files, which work fine on ext3 but gets overwritten because HFS is case-insensitive. I.e. "a.txt" and "A.txt" is the same file. Try creating a case-sensitive HFS filesystem (on a disk image or an external USB disk) and do the clone there. — Thorbjørn Ravn Andersen, Jul 07 '16 at 16:19
@ThorbjørnRavnAndersen: that is the correct answer, you should probably post it as one. — torek, Jul 07 '16 at 17:47
Indeed, there are two versions of these files, in different cases, so git gets confused... — Motiejus Jakštys, Jul 08 '16 at 07:26
Possible duplicate of [Cloning a git repo, and it already has a dirty working directory... Whaaaaa?](https://stackoverflow.com/questions/7383426/cloning-a-git-repo-and-it-already-has-a-dirty-working-directory-whaaaaa) — MarcH, Jan 13 '18 at 01:24

Thorbjørn Ravn Andersen · Accepted Answer · 2021-07-14T10:41:50.063

Even though OS X is a Unix system it is still very different from the most well-known Unix clone Linux. This is due both to historic reasons as OS X is essentially NextStep (which in its time was a revolutionary version of Unix) with a lot of FreeBSD stuff, and Linux is a written-from-the-ground-up kernel with a lot of GNU stuff, as well as political reasons as OS X was designed to succede MacOS 9.

Therefore it is customary that the default HFS filesystem is case-insensitive (like Windows NTFS) as opposed to Linux which traditionally is case-sensitive. In other words - does "A.txt" and "a.txt" refer to the same file or not?

Git is designed by Linus Torvalds who also is the Linux kernel architect for handling the kernel sources, so naturally it has a Linux mindset, and expects files differently named to be different files.

For most uses this doesn't matter, but you have hit one of the situations where it does, namely if there is multiple files in a git repository with the same names if you clone it to a case-insensitive filesystem. Given "A.txt" and "a.txt" again, for Linux both files will exist after the clone, but for the default HFS filesystem on OS X only one file will exist, namely the one created the last (which will then overwrite the previous) one.

Note that git still thinks both files are present as the file system says that "A.txt" and "a.txt" are both present when asked. This is why you are not told that one of them are missing.

The cure is simple. Do your work using a case-sensitive file system. For OS X the simplest way is to create an appropriate disk image using Disk Utility -> File -> New Image and choose the right version of OS X extended as the format. Then double click the image to mount it, and navigate to it in Terminal.app. Then do the clone. You should now have the right sources.

Note however, that you will most likely not be able to do anything with it like building or similar as the OS X compiler toolchain is vastly different from the Linux one. If you want to compile a new kernel, the simplest is to do it on Linux. Virtualbox plus Ubuntu 16.04 works very well for me.

Linux Kernel sources modified on OSX right after clone

1 Answers1

Linked