For files that shouldn't be ignored (at this point, everything but .git, running commit should iterate through each of them, create a blob, and store it in the git database.

• List files that shouldn't be ignored (and thus stored in the db)
• Capture file as a blob (what does this actually mean)
• Compress that blob
• Store that blob in the DB (./git/objects/)
• Write some automated tests

Clippy has some opinions about how I write my rust code. They'll prompt me to think about how I'm writing this thing in un-idiomatic ways and get better.

I've started work on this in a couple ways. 735b60a fixes a bunch of Clippy issues and e505954 gets CI yelling if there are any warnings.

This is mostly done. Except for one final warning:

warning: this `.filter_map` can be written more simply using `.filter`
  --> src/ignore.rs:29:9
   |
29 | /         paths
30 | |             .into_iter()
31 | |             .filter_map(|p| {
32 | |                 if self.ignore_item(&p) {
...  |
35 | |                 Some(p)
36 | |             })
   | |______________^
   |
   = note: #[warn(clippy::unnecessary_filter_map)] on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_filter_map

• Get a failing CI build for outstanding Clippy warnings
• Fix Clippy warnings to get CI in a happy place again

Automated tests should run every time we push code. The simplest path to making this happens seems to be GitHub Actions and the new built-in CI stuff.

A dummy test file should be fine for now. I want to see two things:

1. The color red 💔 somewhere when tests aren't passing (assert!(false))
2. The color green ☘️ somewhere when tests are passing (assert!(true))

Go ahead and leave the fake passing test in until we have our first real one.

Minimal implementation of git-init to get us started. While the full command looks like:

git init [-q | --quiet] [--bare] [--template=<template_directory>]
	  [--separate-git-dir <git dir>]
	  [--shared[=<permissions>]] [directory]

we're just starting with a basic:

git init [directory]

where directory is the path to our new repository.

This is really just about making sure the right directory structure is created for the repository in a way that git will recognize our repo as valid.

Some details:

• If directory isn't specified, default to the current working directory
• If directory doesn't yet exist, create it
• Sure, there's the top-level directory, but all our git-y things go in .git, minimally:
  • .git/objects (a directory)
  • .git/refs (another directory)

What's a tree?

It's like a blob. It's an object. But instead of starting with blob it starts with tree. Like a blob, it even has a space after that first word, followed by the length of the file in bytes! There's even a null byte between the byte length and whatever comes next. Super familiar now, so 👍.

So what's in the body of this object? It's a list of files. They seem to be called entries though, so I've got a variable that needs to be renamed in the existing code to make this non-confusing. Each entry has:

1. File mode (hard-coded to 100644, for now)
2. A space (" ")
3. Name of the file
4. A null byte \0
5. An object ID (20 bytes, represented as hex)

100644 {file_name}\0{20_byte_object_id}

These are listed alphabetically by filename. And joined together with nothing between them ("").

Write the commit object. It looks something like this:

commit 173tree d563e95f9546ba7708a37dc1d61f82a1b4bbcf14
author Count Dracula <count@dracula> 1570466082 -0500
committer Count Dracula <count@dracula> 1570466082 -0500

It is a commit!

It depends on:

• The ID of the tree we're committing
• Author name and email (using env vars GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL)
  • Book is skipping git config stuff for now to get us going, and I'm okay with that
• Committer name and email (treating this the same as author for now)
• The current time (seconds since epoch and a timezone offset: %s %z)
  • Makes for flaky tests currently... git twin and workspace aren't necessarily run in the same second, but often are ¯\_(ツ)_/¯
• The commit message
  • Book is trying to keep things simple to start here and avoiding command line arg... I'm just going to do the arg since I have a library for it and it's less to figure out

Things to do yet:

• Make things less flaky by passing time in as an arg to build the commit
• Add -m and -message as CLI args for the binary
• Update HEAD to point to the commit object
• Make sure multiple files work in a commit
• Make sure commit works for files in subdirectories

Commits beyond the first one should be keeping track of their parent. Add a parent field to these commit objects with the ID of the parent commit.

The first commit should look like it does now, with no parent field in sight.