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) ...

I have been using — and loving — JetBrains Integrated Development Environments (IDEs) and other tools (I like TeamCity a lot!) since effectively version 1 of IntelliJ IDEA since it was released in the early 2000s. Compared to the other IDEs I tried at the time like NetBeans, JBuilder and Eclipse, IntelliJ was just better all around. But the really great thing that I liked about it in addition to its overall look & feel was its keyboard integration. That’s right, keyboard integration. ...

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? ...

As soon as you want to do anything non-trivial with respect to parsing text using Rust (or any language) you should use some kind of parser… Text parsing in Rust with Nom As soon as you want to do anything non-trivial with respect to parsing text using Rust (or any language) you should use some kind of parser implementation. Writing a working parser for anything but the most trivial content is non-trivial. Unless you want to learn parsers (perhaps you’re taking a compiler course), better to use an existing tool/framework. ...

As I continue my journey learning Rust, I thought I’d share some learning related to multithreading and thread locals. I came across an interesting new site called CodeCrafters. The site is another learning site supporting multiple programming languages, but they focus on specific “challenges” with specific tasks to accomplish for each challenge. I’ve worked through a few of them, and I used threads and thread locals on the HTTP server challenge. ...

Way back when, before nice graphical user interfaces, all we had was the terminal. I won’t waste time with a trip down memory lane. Suffice to say there were many cool terminal-based interfaces, and some of us still use terminals (or terminal emulators more likely). And there are still nice terminal-based user interfaces used by many of us, even if that’s just vim or emacs. As I continue my journey learning Rust, I thought I’d take a stab at writing a terminal user-interface (AKA TUI). In this case I will leverage a Rust crate called ratatui. Ratatui provides UI widgets for building a TUI — things like laying out your UI, tabs, tables, scrollbars, and the like. Ratatui focuses on the UI aspects, and leverages other crates for the low level terminal interaction. Several are supported, but the one I chose (and the most common?) is called Crossterm. I am going to focus here more on Ratatui then Crossterm, except as needed. ...