자식 인덱스에는 정확히 무엇이 포함되어 있습니까?

자식 인덱스에는 정확히 무엇이 포함되어 있습니까?

---

Git 인덱스에는 정확히 무엇이 포함되어 있으며 인덱스의 내용을보기 위해 어떤 명령을 사용할 수 있습니까?

---

최신 정보

모든 답변에 감사드립니다. 인덱스가 준비 영역으로 작동하고 커밋 된 것은 작업 트리가 아니라 인덱스에 있음을 알고 있습니다. 인덱스 객체가 무엇인지 궁금합니다. 파일 이름 / 디렉토리 이름, SHA-1 쌍, 가상 트리 종류 일 수 있습니까?

Git 용어 에는 인덱스의 내용을 나열하는 데 사용할 수 있는 배관 명령이 있습니까?

---

Git 책에는 색인 에 포함 된 내용에 대한 기사가 있습니다 .

인덱스는 .git/index경로 이름의 정렬 된 목록을 포함 하는 이진 파일 (일반적으로로 유지됨 )이며, 각각 권한과 BLOB 개체의 SHA1이 있습니다. git ls-files색인의 내용을 보여줄 수 있습니다.

$ git ls-files --stage
100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0   .gitignore
100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0   .mailmap

선정적인 이눔 문제는 그 구조에 대한 좀 더 자세한 내용을 제공합니다 :

인덱스는 git에서 가장 중요한 데이터 구조 중 하나입니다.
경로 목록과 객체 이름을 기록하여 가상 작업 트리 상태를 나타내며 커밋 할 다음 트리 객체를 작성하는 준비 영역 역할을합니다.
상태는 작업 트리의 파일과 반드시 ​​일치 할 필요는 없으며 종종 일치하지 않아도된다는 점에서 "가상"입니다.

---

자세한 내용은 cf. " git / git / Documentation / technical / index-format.txt ":

Git 인덱스 파일의 형식은 다음과 같습니다

모든 이진수는 네트워크 바이트 순서입니다. 달리 명시되지 않는 한
버전 2 가 여기에 설명되어 있습니다.

• 다음으로 구성된 12 바이트 헤더 :
  • 4 바이트 서명 :
    서명은 { ' D', ' I', ' R', ' C'}입니다 ( " dircache"의 약자 )
  • 4 바이트 버전 번호 :
    현재 지원되는 버전은 2, 3 및 4입니다.
  • 32 비트 인덱스 항목 수
• 여러 개의 정렬 된 색인 항목 .
• 확장 :
  확장은 서명으로 식별됩니다.
  Git이 이해하지 못하면 선택적 확장은 무시할 수 있습니다.
  힘내는 현재 캐시 트리를 지원하고 실행 취소 확장을 해결합니다.
  • 4 바이트 확장 서명. 첫 번째 바이트가 ' A'.. ' Z'인 경우 확장자는 선택 사항이며 무시할 수 있습니다.
  • 확장의 32 비트 크기
  • 확장 데이터
• 이 체크섬 이전의 인덱스 파일 내용에 대한 160 비트 SHA-1

---

mljrg 의견 :

인덱스가 다음 커밋이 준비되는 장소 인 경우 커밋 git ls-files -s후에 " "가 아무것도 반환 하지 않는 이유는 무엇입니까?

때문에 인덱스를 추적하는 것을 나타내고 , 오른쪽 커밋 후 마지막 (커밋 없습니다, 무엇을 추적하는 것은 동일하다 git diff --cached반환 아무것도).

그래서 git ls-files -s모든 파일을 추적 목록 (개체 이름, 모드 비트 및 출력에 단수).

해당 요소 (추적 된 요소) 목록은 커밋 내용으로 초기화됩니다.
분기를 전환하면 방금 전환 한 분기에서 참조하는 커밋으로 인덱스 내용이 재설정됩니다.

---

Git 2.20 (Q4 2018)은 IEOT (Index Entry Offset Table )를 추가합니다 .

참조 77ff112 커밋 , 3,255,089 커밋 , abb4bb8 커밋 , c780b9c 커밋 , 3b1d9e0 커밋 , 371ed0d 커밋 에 의해 (2018년 10월 10일) 벤 씩씩한를 ( benpeart) . Nguyễn Thái Ngọc Duy ( )의 commit 252d079 (2018 년 9 월 26 일)를
참조하십시오 . ^{(의해 병합 Junio C 하마노 - - 에 커밋 e27bfaa 19 시월 2018)}pclouds
gitster

ieot : IEOT (Index Entry Offset Table) 확장 추가

이 패치를 사용하면 캐시에로드 및 변환을 효율적으로 멀티 스레딩 할 수있는 인덱스에 추가 데이터를 추가하여 인덱스로드의 CPU 비용을 처리 할 수 ​​있습니다.

인덱스 파일의 캐시 항목 블록에 오프셋 테이블 인 (선택적) 인덱스 확장을 추가하여이를 수행합니다.

V4 인덱스에 대해이 작업을 수행하려면 캐시 항목을 쓸 때 이전 항목의 경로 이름이 완전히 다른 것처럼 현재 항목을 인코딩하여 접두어 압축을 주기적으로 "재설정"하고 IEOT에 해당 항목의 오프셋을 저장합니다. .
기본적으로 V4 인덱스를 사용하면 접두사 압축 항목 블록으로 오프셋을 생성합니다.

으로 새로운 index.threads 설정 설정 , 인덱스 로딩 이제 빠릅니다.

---

결과적으로 ( IEOT 사용 ), 7bd9631을 커밋read-cache.c load_cache_entries_threaded() 하여 Git 2.23 (Q3 2019) 의 기능을 정리하십시오 .

See commit 8373037, commit d713e88, commit d92349d, commit 113c29a, commit c95fc72, commit 7a2a721, commit c016579, commit be27fb7, commit 13a1781, commit 7bd9631, commit 3c1dce8, commit cf7a901, commit d64db5b, commit 76a7bc0 (09 May 2019) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit c0e78f7, 13 Jun 2019)}

read-cache: drop unused parameter from threaded load

The load_cache_entries_threaded() function takes a src_offset parameter that it doesn't use. This has been there since its inception in 77ff112 (read-cache: load cache entries on worker threads, 2018-10-10, Git v2.20.0-rc0).

Digging on the mailing list, that parameter was part of an earlier iteration of the series, but became unnecessary when the code switched to using the IEOT extension.

---

Bit by bit analysis

I've decided to do a little testing to better understand the format and research some of the fields in more detail.

Results bellow are the same for Git versions 1.8.5.2 and 2.3.

I have marked points which I'm not sure / haven't found with TODO: please feel free to complement those points.

As others mentioned, the index is stored under .git/index, not as a standard tree object, and its format is binary and documented at: https://github.com/git/git/blob/master/Documentation/technical/index-format.txt

The major structs that define the index are at cache.h, because the index is a cache for creating commits.

Setup

When we start a test repository with:

git init
echo a > b
git add b
tree --charset=ascii

The .git directory looks like:

.git/objects/
|-- 78
|   `-- 981922613b2afb6025042ff6bd878ac1994e85
|-- info
`-- pack

And if we get the content of the only object:

git cat-file -p 78981922613b2afb6025042ff6bd878ac1994e85

We get a. This indicates that:

• the index points to the file contents, since git add b created a blob object
• it stores the metadata in the index file, not in a tree object, since there was only a single object: the blob (on regular Git objects, blob metadata is stored on the tree)

hd analysis

Now let's look at the index itself:

hd .git/index

Gives:

00000000  44 49 52 43 00 00 00 02  00 00 00 01 54 09 76 e6  |DIRC.... ....T.v.|
00000010  1d 81 6f c6 54 09 76 e6  1d 81 6f c6 00 00 08 05  |..o.T.v. ..o.....|
00000020  00 e4 2e 76 00 00 81 a4  00 00 03 e8 00 00 03 e8  |...v.... ........|
00000030  00 00 00 02 78 98 19 22  61 3b 2a fb 60 25 04 2f  |....x.." a;*.`%./|
00000040  f6 bd 87 8a c1 99 4e 85  00 01 62 00 ee 33 c0 3a  |......N. ..b..3.:|
00000050  be 41 4b 1f d7 1d 33 a9  da d4 93 9a 09 ab 49 94  |.AK...3. ......I.|
00000060

Next we will conclude:

  | 0           | 4            | 8           | C              |
  |-------------|--------------|-------------|----------------|
0 | DIRC        | Version      | File count  | ctime       ...| 0
  | ...         | mtime                      | device         |
2 | inode       | mode         | UID         | GID            | 2
  | File size   | Entry SHA-1                              ...|
4 | ...                        | Flags       | Index SHA-1 ...| 4
  | ...                                                       |

First comes the header, defined at: struct cache_header:

• 44 49 52 43: DIRC. TODO: why is this necessary?

• 00 00 00 02: format version: 2. The index format has evolved with time. Currently there exists version up to 4. The format of the index should not be an issue when collaborating between different computers on GitHub because bare repositories don't store the index: it is generated at clone time.

• 00 00 00 01: count of files on the index: just one, b.

Next starts a list of index entries, defined by struct cache_entry Here we have just one. It contains:

• a bunch of file metadata: 8 byte ctime, 8 byte mtime, then 4 byte: device, inode, mode, UID and GID.

  Note how:

  • ctime and mtime are the same (54 09 76 e6 1d 81 6f c6) as expected since we haven't modified the file

    The first bytes are seconds since EPOCH in hex:

    date --date="@$(printf "%x" "540976e6")"
    

    Gives:

    Fri Sep  5 10:40:06 CEST 2014
    

    Which is when I made this example.

    The second 4 bytes are nanoseconds.

  • UID and GID are 00 00 03 e8, 1000 in hex: a common value for single user setups.

  All of this metadata, most of which is not present in tree objects, allows Git to check if a file has changed quickly without comparing the entire contents.

• at the beginning of line 30: 00 00 00 02: file size: 2 bytes (a and \n from echo)

• 78 98 19 22 ... c1 99 4e 85: 20 byte SHA-1 over the previous content of the entry. Note that according to my experiments with the assume valid flag, the flags that follow it are not considered in this SHA-1.

• 2 byte flags: 00 01

  • 1 bit: assume valid flag. My investigations indicate that this poorly named flag is where git update-index --assume-unchanged stores its state: https://stackoverflow.com/a/28657085/895245

  • 1 bit extended flag. Determines if the extended flags are present or not. Must be 0 on version 2 which does not have extended flags.

  • 2 bit stage flag used during merge. Stages are documented in man git-merge:

    • 0: regular file, not in a merge conflict
    • 1: base
    • 2: ours
    • 3: theirs

    During a merge conflict, all stages from 1-3 are stored in the index to allow operations like git checkout --ours.

    If you git add, then a stage 0 is added to the index for the path, and Git will know that the conflict has been marked as solved. TODO: check this.

  • 12 bit length of the path that will follow: 0 01: 1 byte only since the path was b

• 2 byte extended flags. Only meaningful if the "extended flag" was set on the basic flags. TODO.

• 62 (ASCII b): variable length path. Length determined in the previous flags, here just 1 byte, b.

Then comes a 00: 1-8 bytes of zero padding so that the path will be null-terminated and the index will end in a multiple of 8 bytes. This only happens before index version 4.

No extensions were used. Git knows this because there would not be enough space left in the file for the checksum.

Finally there is a 20 byte checksum ee 33 c0 3a .. 09 ab 49 94 over the content of the index.

---

The Git index is a staging area between your working directory and your repository. You can use the index to build up a set of changes that you want to commit together. When you create a commit, what is committed is what is currently in this index, not what is in your working directory.

To see what is inside the index, issue the command:

git status

When you run git status, you can see which files are staged (currently in your index), which are modified but not yet staged, and which are completely untracked.

You can read this. A Google search throws up many links, which should be fairly self sufficient.

---

Here is what you exactly needed, use this command.

$ binwalk index

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
1717          0x6B5           Unix path: /company/user/user/delete.php
1813          0x715           Unix path: /company/user/user/get.php
1909          0x775           Unix path: /company/user/user/post.php
2005          0x7D5           Unix path: /company/user/user/put.php
3373          0xD2D           Unix path: /urban-airship/channel/channel/post.php
3789          0xECD           Unix path: /urban-airship/named-user/named-user/post.php
3901          0xF3D           Unix path: /user/categories/categories/delete.php
4005          0xFA5           Unix path: /user/categories/categories/get.php
4109          0x100D          Unix path: /user/categories/categories/put.php
4309          0x10D5          Unix path: /user/favorites/favorites/delete.php

참고URL : https://stackoverflow.com/questions/4084921/what-does-the-git-index-contain-exactly