title: Why do git objects include a length and a delimiter as metadata?
body: <p>I'm doing a git course, learning about git objects.</p>
  <p>It's not entirely clear why every git object stores metadata the way it does.</p>
  <p>Every object prepends a header:</p>
  <pre><code>header = &quot;blob #{content.length}\0&quot;
  </code></pre>
  <p>Apparently, there are 4 types of git objects:</p>
  <ul>
  <li>Blob</li>
  <li>Tree</li>
  <li>Commit</li>
  <li>Annotated Tag</li>
  </ul>
  <p>That's 4 possible options, or 2 bits of data.
  Even allowing for future expansion, this could have been made into a single byte, prepended to each object.</p>
  <p>Knowing that the first byte will always be the type, and having the filesystem tell you the length of the file, you can easy calculate the length of the data in the object as <code>file_size - 1 byte</code>. This removes the need for a length field, or a delimiter, since your metadata is now a constant length.</p>
  <p>Even with the current design, where the type field is a variable length string, knowing the object's file size, which the filesystem (ex: ext4) will tell you, and the header length, which you can figure out by reading up to, and including the delimiter, it seems like you can easily figure out the length of the data stored inside the object (<code>file_size - header_length</code>).</p>
  <p>Is there a reason Torvalds (or whoever) chose to use a string to represent the object type, to include the content length (which can be calculated), and to include a delimiter?</p>