CODEWITHSUNDEEP
git
abcdabcd987
abcdabcd987

Reputation: 2063

Why git prepends a `TYPE LENGTH\0` header in object files?

I read the Git Pro and knew that git prepends an header to object file, which is TYPE LENGTH\0, for example:

header = "blob #{content.length}\0"

But I'm wondering for what purpose git keeps this header?

Upvotes: 2

Views: 80

Answers (1)

torek
torek

Reputation: 489818

It's true that in almost all cases, by the time you have the SHA-1 you know what kind of object you should get: if you start with a branch reference, you should get a commit; if you start with a commit and its tree you must get a tree; and if you have a tree-ID and read its object, each entry has a mode that tells you what the object type should be.

But what if you have a tag reference? If you read .git/refs/tags/v2.2.2 and get da5eda36576c1d45a52f7f60a9e5372aa4e2bb58, what type do you expect to find for object da5eda36576c1d45a52f7f60a9e5372aa4e2bb58?

If v2.2.2 is a lightweight tag, da5eda36576c1d45a52f7f60a9e5372aa4e2bb58 will probably be a commit, but it could be a tree or even a blob. If it's an annotated tag, da5eda36576c1d45a52f7f60a9e5372aa4e2bb58 will be a tag object.

You could read the target object and guess, but if it's a blob object, it might look like a valid annotated tag, commit, or tree. The only sure way to know is to read the object type.

Besides the above, git cat-file -t tells you the type, which it can only find from the underlying object. Of course, if git were designed differently there might not be a git cat-file -t. But tags in particular require the type, and once it's there, exposing it via git cat-file -t seems reasonable as well.

Upvotes: 1

Related Questions