Git

In this blog I continue my journey with Rust and Git, focusing on creating the last two object types in Git — the tree and the commit. As you may recall from previous post in this series, a tree object represents a single level of a directory tree, with the file’s name, permissions and object hash. A commit object is what most people are familiar with, and it contains references (via object hashes) to a tree for files in the commit, a reference to the parent commit if any (e.g. the very first commit in a repo has no parent), the name of the author and committer (which are allowed to be different) and finally the commit message. If you sign your commit, this ends up as text in the comment. ...

In this latest blog on Git internals with Rust, I will focus on the ls-tree command in Git. You can find the earlier posts here: Part 1 — git init Part 2 — git hash-object Part 3 — refactoring Part 4 — git cat-file The ls-tree command is similar to doing an ls in a terminal emulator. It lists the contents of tree objects in Git. The Git object model looks like this (copied from Part 2) ...

In this post we’ll cover the Git cat-file command. Previous posts in this series are Part 1 — git init Part 2 — git hash-object Part 3 — refactoring The Git cat-file command let’s you dump the contents of a Git object. You cannot view Git object files directly since they are compressed as well as having headers, as we saw in the second post on hash-object. The cat-file command is essentially the inverse of the hash-object command. ...

In this post we continue our journey with Rust and Git. If you haven’t read the previous posts, you can find them here Part 1 — git init Part 2 — git hash-object At the end of Part 2 I said the next blog would be on cat-file. Sorry for the bait and switch, but I wanted to do this refactoring, so I snuck this in. We’ll definitely get to cat-file next time. While this post is mostly standalone, there are aspects of the prior posts that will probably help to understand this post better. ...

This post continues from where I left off in the first post that covered creating a new empty repository. You can read it here. To briefly summarize the goal of this series of posts, I am on a journey to learn Rust and for me the best way is doing “real” stuff. In this case I’m looking at the internals of Git, by implementing some of the many commands available. After the first post I am able to create a new repository. Let’s start to look at what Git stores and how it does so. As we saw in the first post, after git init we have a directory .git/objects. Content is stored in files under that base objects directory by using a SHA-1 hash of the contents being stored. Git provides a command git hash-object which allows generating the hash based on content, and optionally writing that file to .git/objects. However, that doesn’t mean that git hash-object is just a fancy wrapper around sha1sum or similar tools. ...

Have you ever wondered how Git does what it does? What happens when you do a commit? You can read about some of this in the Git Book free online, like in Chapter 10 on Git Internals. But it doesn’t give you all the details, as I discovered. And I wanted another interesting “project” to help me on my continuing journey learning Rust. So why not poke around under the Git hood? ...