allow-empty

allow-empty is an experimental blog by @danott. Git commits in the github.com/danott/allow-empty repository are the posts.

Grab the RSS feed while you're here.

commit
a2be7ec023cb6920a295bd0381a42a53de628bff
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Thu Jan 18 15:33:41 2024 -0500
Reply:
GitHub

Create a post from GitHub.com

Back in 09e70ee I said there was no affordance for authoring posts on https://github.com. But that’s not entirely true. Using the in-browser file creation tools makes it possible. That’s what I’m doing right now.

I navigated to https://github.com/danott/allow-empty/new/main. I’m creating an empty file in the root of the project called .allow-commit. I could just as easily put the number 1 in it. Or the current time. Or anything. Any change will allow me to write a commit in this tiny modal on GitHub.com.

I assume this won’t be wrapped to 80 characters. Committing the changes will let me know.

commit
e6efa32ab6a439a0d288907c915dc7ded31c92a1
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Thu Jan 18 09:10:22 2024 -0500
Reply:
GitHub

The shame of git push --force

This blog is only 11 posts deep. I’ve learned a few things while writing it.

I wanted to fix some small things in the existing entries. Mostly making sure I adequately linked out to references. And I surrounded bare links with carets so Kramdown will turn them into real anchor tags with an href.

I kicked off this process with a git rebase -i --root. I picked some commits and reworded others. All said and done, the edits are made.

But making these edits changes git history, including the sha of each commit. I’ve been calling it a hash. Should I update that in code that builds the HTML representation?

I’ve created a tag to capture the state before force pushing. Just in case I’ve lost something to history that I might want to resurrect.

commit
7b43b4bfcab94cbb2576783ba7be592b45dc148d
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Thu Jan 18 08:36:52 2024 -0500
Reply:
GitHub

Some small typography tweaks

I want dashes for lists. And I want them to appear to the left of the content. I’m confident there’s a proper typography term for this. But I’ve forgotten it.

Do the same for > indicating a blockquote.

commit
4d0d13b269dba60621122778f800fdfebfdf9849
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Thu Jan 18 08:22:22 2024 -0500
Reply:
GitHub

Add naive pagination to post pages

I woke up thinking about blog idioms. Some folks like to scroll through a collection. Other folks like to click through that same collection.

Scrolling was already solved. This commit solves for clickable collection perusal.

“Sorting” is an interesting problem space. What does “previous” mean? “Next?” It always depends on how the problem is being approached.

Previous could mean two things:

  • The commit that precedes this one in the git log. What git would refer to as the parent.
  • The commit that precedes this one when reading top to bottom, left to right, like words on a page.

I went with the former as my interpretation. This also brings up other musings about sort order.

There is not a guarantee that a commit’s parent has a commit time (or author time) that represents an earlier point in chronological history. I haven’t had to Commit.all.sort_by(&:anything) yet. But I can imagine a world where I’d have to if I really push this idea to it’s outer limits with multiple collaborators committing on different schedules from different time zones.

Neat!

commit
66a88ef927379c3a98c8b697a753480d23f60f71
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Wed Jan 17 23:57:46 2024 -0500
Reply:
GitHub

Add a README

On a long enough horizon I’ll want to make changes to this project. Leave myself (and any curious onlookers) a README to introduce the project.

https://github.com/danott/allow-empty.

commit
9011e995f237f0e7e4a6fe0c3ac09b2bcfc07e27
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Wed Jan 17 23:19:45 2024 -0500
Reply:
GitHub

Make the HTML representation beautiful

git log --pretty is pretty in the console. I want this git log as blog to be pretty in the browser.

I dusted off my old CSS chops and made it look the way I wanted to. There is support for light mode and dark mode.

Finding a blessed list of solarized colors is more difficult than initially imagined. I ended up in the solarized-css project, looking at a .styl file. I think this is sass?

Some regex-foo in VSCode translated the assumed-sass declarations into CSS custom properties. I’m not using the majority of them. But I decided to keep the translation in the source code in case I ever need to generate them again.

I ended up reaching for ERB to make sense of my rendering. String interpolation can get you so far. But sometimes the mental model is worth the reach for complexity.

commit
1efe0d694c11068c5df483695388bae45319baf1
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Wed Jan 17 20:45:57 2024 -0500
Reply:
GitHub

Today I learned GitHub Actions fetch-depth

My deploy worked! This static site was available at https://allow-empty.danott.website. But there was only one commit represented.

My hunch was that actions/checkout@v4 checks out the minimal amount of data.

Yep! It’s right there in the README. Towards the top.

Only a single commit is fetched by default, for the ref/SHA that triggered the workflow. Set fetch-depth: 0 to fetch all history for all branches and tags.

commit
1b99f2f4dda463d0a84db5e8d7b8455ba5add07e
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Wed Jan 17 20:38:41 2024 -0500
Reply:
GitHub

Resolve error in GitHub Actions

GitHub actions complained that there was no .ruby-version in this repository. I can satisfy that requirement.

Seeing this error reminded me that GitHub Actions will also complain about Gemfile.lock not explicitly supporting x86_64-linux. I solved this same problem on https://danott.website. I’ll proactively head it off in this project.

commit
335dfae5c1ee33e721118574072caafc116d5950
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Wed Jan 17 20:33:20 2024 -0500
Reply:
GitHub

Keep experimenting with allow-empty

This is ironic. The experiment continues with a first commit that does not require an --allow-empty flag.

Turning commits into a static site is something I find fascinating. Even a month later.

I’ve taken what I’ve learned from building https://www.danott.co and https://danott.website and distilled it down into a minimal Rakefile. The Rakefile leans heavily into the origins of make. Generating static site files based on the existence of other static site files.

I also took a first go at building GitHub Pages using a bespoke action. Here goes nothing.

commit
09e70ee852f4c99d41d527880c0bb4218be02135
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Fri Dec 1 08:29:21 2023 -0500
Reply:
GitHub

When does creation happen?

I’m continuing to muse on this experiment. It occurs to me that there is no affordance in the GitHub interface for adding an empty commit. Creating posts in this format MUST happen from a remote git repository. Outside the veneers of GitHub.

Is the distinction between git and GitHub apparent to everyone? GitHub is an interface into the raw data stored in git. With useful layers of guiding process and organized collaboration. Usually git commits tell the story of an artifact being produced. And GitHub pull requests tell the story of refinements to that artifact. Both automated and human.

How would editing a post work in this format?

git commit --amend
git push --force

There would be no record that anything changed. Unless someone was keeping a remote git repository and encountered the need to reconcile differences.

A non-fungible log of events could ensure that all events stay on public record. NFT? Not for this.

What is a blog? Is it the author’s words being captured and broadcast? Does it include the commentary and interaction that get layered on top via an interface? Does it include the presentation and interaction? There’s probably a spectrum.

GitHub is interesting because the data store of the commits and blobs that make up the working tree (git) is distinctly portable from the layers of presentation, interaction, and collaboration wrapped around those commits (GitHub). And I’m not even talking about the working tree that makes most git repositories useful. There are layers of useful information. In other forms of writing this editing process is usually invisible. The remnant is a mention of thanks in an introduction or conclusion. With git and GitHub we can see the signals of collaboration and refinement. If one is committed to writing about their writing with the same vigor as writing the artifact they’re trying to produce.

Using empty commits as the primary data store loses a layer of information. It will never be clear why something changed. Which is often a mystery in writing. And in writing about writing. And in editing writing about writing. And what about editing writing about editing writing?

How did an author choose to manage the tension of competing values while editing writing about editing writing? What words did they choose to explain how they managed the tension? Did that editing process itself have subroutines of evaluation? Exploring divergent branches of possibilities while considering competing values can be expressed in git. All these layers of execution and evaluation are useful to someone who is deeply interested in learning the crafts. It’s feedback loops all the way down.

And then on a blog they get compressed into a single layer. Ready for sediment to pile on or erosion to run its course.

commit
8c047eb32a6b5e1ae722615b4ab9d11b5dea8339
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Thu Nov 30 23:54:11 2023 -0500
Reply:
GitHub

Comment moderation is built in

Every commit in GitHub gets it’s own page. Here’s the pages so far:

And each page allows for comments on that commit. Comments require authentication via GitHub. Conversations can be locked.

I was focused on RSS...but there’s an entire notification system built in. If someone wants to receive notifications about every commit on a repository they can.

Can you comment on any file in a GitHub repository? No, you cannot.

What a fascinating idea for broadcast, opt-in subscribing, and a medium for civil responses.

commit
bb611047918c1293846ce1ba44c1aa3249f3bf0b
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Thu Nov 30 23:47:18 2023 -0500
Reply:
GitHub

Now available on RSS

Voilà! A push to GitHub and now this blog is available via RSS:

https://github.com/danott/allow-empty/commits.atom

Writing in vim with autowrapping at 80 characters is a different writing experience. Reading in Reeder with the commit formatted as a code block is a different reading experience. This is not the ideal format for blogging. But it’s interesting to embrace the constraints and try to do something dumb on a Thursday night.

commit
283dd396bfd642d1363d94a2e736b1604467b635
Author:
Dan Ott <danott@users.noreply.github.com>
Date:
Thu Nov 30 23:37:04 2023 -0500
Reply:
GitHub

This could be a blog

I’ve been tinkering with GitHub, RSS, blogs, etc. Did you know every GitHub repository has an RSS feed of recent commits? It’s true. I ran git commit --allow-empty and began typing. This could become a blog titled “allow empty”. It’s restricted to git commits. Just plain text wrapped at 80 characters. Isn’t that neat.