克隆后立即在OSX上修改Linux内核源 [英] Linux Kernel sources modified on OSX right after clone

问题描述

当我在OS X上克隆Linux源代码时，它们会立即被更改，并且git reset --hard不会带回内容.这是一个完整的会话:

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 <[e-mail]>
- * 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;
 };

系统信息:

• 文件系统:记录的HFS +
• 操作系统: OS X 10.11.5(15F34)
• git版本: 2.9.0
• ~/.gitconfig仅具有[user]条目.

• 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?

推荐答案

即使OS X是Unix系统，它与最著名的Unix克隆Linux仍然有很大的不同.这是由于历史原因造成的，因为OS X本质上是NextStep(在当时是Unix的革命性版本)，其中包含许多FreeBSD内容，而Linux是从头开始编写的内核，其中包含许多内容. GNU的东西以及OS X的政治原因旨在取代MacOS 9.

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.

因此，习惯上，默认的HFS文件系统不区分大小写(例如Windows NTFS)，而Linux通常是区分大小写的.换句话说-"A.txt"和"a.txt"是否引用相同的文件?

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由Linus Torvalds设计，Linus Torvalds也是Linux内核架构师 ，负责处理内核源代码，因此自然而然地，它具有Linux思维方式，并且期望文件的名称与 be 不同的文件.

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.

对于大多数用途而言，这无关紧要，但是您遇到了其中一种情况，即，如果将git存储库中的多个文件克隆到不区分大小写的文件系统中，那么它们是否具有相同名称的多个文件.再次给定"A.txt"和"a.txt"，对于Linux，两个文件都将在克隆之后存在，但是对于OS X上的默认HFS文件系统，仅存在一个文件，即创建的一个文件.最后一个(它将覆盖之前的一个).

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.

请注意，git仍然认为两个文件都存在，因为文件系统在询问时都说"A.txt"和"a.txt"都存在.这就是为什么您没有被告知其中一个人失踪的原因.

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

治愈很简单.使用区分大小写的文件系统进行工作.对于OS X，最简单的方法是使用磁盘工具"->文件"->新映像"创建合适的磁盘映像，然后选择正确的OS X版本作为格式扩展.然后双击该图像以将其安装，并在Terminal.app中导航至该图像.然后进行克隆.您现在应该拥有正确的来源.

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.

但是请注意，由于OS X编译器工具链与Linux截然不同，因此您极有可能无法执行任何操作，例如构建或类似操作.如果要编译新内核，最简单的方法是在Linux上进行编译. Virtualbox加上Ubuntu 16.04对我来说很好用.

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.

这篇关于克隆后立即在OSX上修改Linux内核源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！