100在git diff命令中意味着什么?我知道这是git文件模式,但请详细介绍此文件模式

发布于 2025-01-17 17:52:17 字数 152 浏览 3 评论 0原文

新文件模式100644 这 100 在这里。我知道最后三个数字的含义。但不是这个文件模式的意思。请给我所有信息。我喜欢获得全面的信息。

我尝试搜索有关此文件模式的信息,但我只获得有关文件权限的信息,而不是此文件模式的信息。

new file mode 100644
This 100 Here. I Know Last Three Numbers Meaning. But Not This File Mode Means. And Please Give Me All Information About. I Love To Be Fully Informed.

I Tried Searching About This File Mode But I Only Get Information About File Permission, Not This File Mode.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

靑春怀旧 2025-01-24 17:52:17

根据 git document

该代码是一系列的位,以八核表示,从最大到最小的

  1. 4位用于文件类型
    • 1000-常规文件
    • 1010-符号链接
    • 1110- git链接
  2. 3未使用的位
  3. 9位用于权限(仅644或755),

因此您的示例100644将二进制转换为

001 000 000 000 110 100 100 100

文件类型:1000-常规文件
未使用的位:000
权限:110 100 100-644

,看来树也没有权限的类型代码0100,尽管我看不到文档中指定的类型代码。

According to the git documentation:

The code is a series of bits represented in octodecimal, from largest to smallest

  1. 4 bits for the file type
    • 1000 - regular file
    • 1010 - symbolic link
    • 1110 - git link
  2. 3 unused bits
  3. 9 bits for the permissions (644 or 755 only)

So your example of 100644 translates into binary as

001 000 000 110 100 100

file type: 1000 - Regular file
unused bits: 000
permissions: 110 100 100 - 644

It appears that trees also get a type code 0100 with no permissions, though I don't see that specified in the documentation.

不甘平庸 2025-01-24 17:52:17

Git树对象中的条目只能具有五个不同的“文件模式”。例如,我当前的git源代码包含这些条目:

040000 tree fe75d26ce528361a9ef3063415db408a7a1ca189    Documentation
120000 blob 81052262e0e43711f308ebc67a371def932cdccc    RelNotes
100755 blob 205541e0f7f81b1df4061215ae34a2742a45475d    generate-cmdlist.sh
100644 blob a25940d72e84e1ad6daba76a6c2845f320bc4df3    git.c
160000 commit 855827c583bc30645ba427885caa40c5b81764d2  sha1collisiondetection

,这些模式为

  • 对于常规文件100755
  • 100644,用于执行文件
  • 040000 对于子树(目录)
  • 120000对于符号链接
  • 160000对于子模块,

Git的作者可以选择任何文本令牌来识别这五个模式,但是对于历史原因,他们选择将它们写成,就像它们是与st_mode在c代码中以八分值表示的st_mode中相同的值。这种任意选择的证明是值160000永远不会在struct Stat中发生(它将是s_ifdir | s_iflnk行为良好的系统)。

An entry in a Git tree object can have only five different "file modes". For example, my current Git source code contains these entries among many others:

040000 tree fe75d26ce528361a9ef3063415db408a7a1ca189    Documentation
120000 blob 81052262e0e43711f308ebc67a371def932cdccc    RelNotes
100755 blob 205541e0f7f81b1df4061215ae34a2742a45475d    generate-cmdlist.sh
100644 blob a25940d72e84e1ad6daba76a6c2845f320bc4df3    git.c
160000 commit 855827c583bc30645ba427885caa40c5b81764d2  sha1collisiondetection

The modes are

  • 100644 for a regular file
  • 100755 for an executable file
  • 040000 for a sub-tree (a directory)
  • 120000 for a symbolic link
  • 160000 for a submodule

The writers of Git could have chosen any text tokens to identify these five modes, but for historical reasons, they chose to write them as if they were the same values that would be found in st_mode of a struct stat in C code, written as octal value. Proof of this arbitrary choice is that the value 160000 would never occur in a struct stat (it would be S_IFDIR|S_IFLNK, an impossibility on a well-behaved system).

淡墨 2025-01-24 17:52:17

看来 filemode 是指可执行位(而不是所有权限)

不建议使用 core.fileMode 。它仅寻址模式的可执行位,而不是读/写位。

根据 Git-Config 的文档

core.fileMode
Tells Git if the executable bit of files in the working tree is to be honored.

Some filesystems lose the executable bit when a file that is marked as executable is checked out, or checks out a non-executable file with executable bit on. git-clone[1] or git-init[1] probe the filesystem to see if it handles the executable bit correctly and this variable is automatically set as necessary.

A repository, however, may be on a filesystem that handles the filemode correctly, and this variable is set to true when created, but later may be made accessible from another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a Cygwin created repository with Git for Windows or Eclipse). In such a case it may be necessary to set this variable to false. See git-update-index[1].

The default is true (when core.filemode is not specified in the config file).

It seems filemode refers to the executable bit (and not all permissions)

The use of core.fileMode is not advised. It just addresses the executable bit of mode, not the read/write bits.

As per the documentation of Git-Config

core.fileMode
Tells Git if the executable bit of files in the working tree is to be honored.

Some filesystems lose the executable bit when a file that is marked as executable is checked out, or checks out a non-executable file with executable bit on. git-clone[1] or git-init[1] probe the filesystem to see if it handles the executable bit correctly and this variable is automatically set as necessary.

A repository, however, may be on a filesystem that handles the filemode correctly, and this variable is set to true when created, but later may be made accessible from another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a Cygwin created repository with Git for Windows or Eclipse). In such a case it may be necessary to set this variable to false. See git-update-index[1].

The default is true (when core.filemode is not specified in the config file).
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文