threads / discuss / 51301

Understanding last ~28 bytes of index file

Subject: Understanding last ~28 bytes of index file

## tl;dr

2 messages between Jun 13, 2019 and Jun 13, 2019.

replies: 1people: 2as markdown or json

Farhan Khan· Jun 13, 2019, 06:32 UTC · lore
Hi all,

I am trying to understand how the index (.git/index) file works. When looking through extensions, it loops until it reaches the last 28 bytes (SHA size + 8). This is referenced here. https://github.com/git/git/blob/master/read-cache.c#L1933 What do the last 28 bytes consist of? Where in the source are bytes written?

I am trying to understand how to reproduce the index file and am not sure how this part works.

Thank you, --- Farhan Khan PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE

Jeff King· Jun 13, 2019, 17:09 UTC · re: Farhan Khan · lore

Re: Understanding last ~28 bytes of index file

On Thu, Jun 13, 2019 at 06:32:03AM +0000, Farhan Khan wrote:
Show 5 quoted lines
> I am trying to understand how the index (.git/index) file works. When
> looking through extensions, it loops until it reaches the last 28
> bytes (SHA size + 8). This is referenced here.
> https://github.com/git/git/blob/master/read-cache.c#L1933
> What do the last 28 bytes consist of? Where in the source are bytes written?

It is not that the last 28 bytes are magical. It is that you must have at least 28 bytes remaining in the file for there to be any extension. 20 of those are the trailing sha1 hash (which are written as part of the hashfile code in csum-file.c).

And then for there to be an extension, it must have 8 bytes of name and length, which will then be followed by however many bytes the length indicated. After parsing that, we check to see if there are enough bytes for another extension, and so on.

To find where the index extension blocks themselves are written, perhaps grep for write_index_ext_header(), which should be called before writing out the data for each.

-Peff

← back to recent threads