Dr. Aris Thorne stared at the shimmering temporal rift, its edges flickering like a corrupted display. He wasn't just looking at a gateway through time – he was looking at a living, breathing Git repository of reality itself.

"Status check," he muttered, fingers dancing across the holographic interface. "Current branch: timeline-main. Last commit: 'Catastrophe at Point Zero' by User:Humanity."

Three days ago, humanity had triggered the Cascade Event – a chain reaction of temporal paradoxes that threatened to unravel existence. Now Aris, the last Temporal Archivist, was attempting something never before conceived: git revert on reality itself.

"Creating new branch: 'fix-attempt-1'," he announced to the empty lab. The temporal rift stabilized, showing a parallel timeline branching off from moments before the disaster.

Aris stepped through, materializing in the control room of the Chronos Facility, right as the ill-fated experiment was about to begin. He knew the command sequence by heart – the one that would prevent the Cascade.

But as he approached the console, he froze. His younger self was there, looking determined but naive. If Aris intervened, would he create a merge conflict with his own existence?

"Branching again," he decided, retreating to the safety of the temporal nexus. "Creating 'fix-attempt-2' from an earlier commit."

This time he arrived hours earlier, when the facility was still empty. He carefully modified the experiment parameters, ensuring the Cascade could never occur. Satisfied, he returned to his present.

The lab was unchanged. The rift still showed the corrupted timeline.

"Failed merge," Aris realized with dawning horror. "Reality rejected the patch."

Days turned into weeks as Aris created dozens of branches, each attempting to fix the timeline. He tried git cherry-pick of successful moments from history, git rebase of civilization's achievements, even git bisect to isolate the exact commit that had broken everything.

Nothing worked. Each attempt was rejected by the cosmic repository, leaving him with countless abandoned branches floating in temporal limbo.

Exhausted, Aris collapsed before the interface. "Git log --oneline --graph," he whispered, watching the tree of failed attempts bloom across the display. It was beautiful in its complexity – a constellation of what-ifs and could-have-beens.

That's when it hit him. He'd been trying to fix the timeline, to restore a previous commit. But what if the solution wasn't to revert, but to evolve?

"Creating new branch: 'transcendence'," he declared with renewed energy. "Not from any previous commit, but from the current corrupted state."

He stepped through into the fractured timeline, where temporal paradoxes manifested as impossible architecture and shifting landscapes. Instead of fighting the chaos, he embraced it. He worked with the anomalies, finding patterns in the madness.

Aris discovered that the Cascade wasn't an error – it was evolution. Humanity had outgrown its linear timeline, and reality was attempting to branch into a multidimensional existence.

"Merge request," he transmitted to the temporal repository. "Not to fix, but to complete the transformation."

The rift stabilized, its chaotic energy resolving into something new and coherent. Aris watched as all his abandoned branches began to merge into this new reality, each failed attempt contributing something essential to the final design.

When he returned to his lab, everything was different yet familiar. The temporal rift was gone, replaced by a window showing infinite timelines coexisting harmoniously.

Aris smiled at the new interface displaying the transformed reality. "Current branch: timeline-multiverse. Last commit: 'Embrace the Chaos' by User:Humanity."

He had learned the ultimate lesson of temporal manipulation: sometimes the best commit isn't a fix, but a feature.

I built something I've wanted for a while within an hour using Claude Code (Sonnet 4.5).
It's a LLM conversations viewer, available for everyone to use at https://tomzxcode.github.io/llm-conversations-viewer.
It is a single page application, 100% client-side.
You can use it to view conversations exported from various LLM platforms (e.g., ChatGPT, Claude, etc.) in a nice interface.
It can also be used to share conversations with others so that they can view them, using https://tomzxcode.github.io/llm-conversations-viewer/?url=url-to-json-or-zip (such as a raw Gist URL).
It can be useful if you use many platforms through their clients (web or mobile) and would like to be able to search those conversations in one place.
Play with it and let me know what you think!
Repository here

The readability index is a metadata field added to articles on this blog to help readers quickly assess whether an article is appropriate for their level of expertise and available attention.

The scale

Articles are rated on a 0-5 scale based on their readability:

• 0 - Personal notes: Content that is only meaningful to me. These are often shorthand notes, context-dependent references, or incomplete thoughts that lack the necessary background for others to understand.

• 1 - Cryptic: Readable but highly condensed or assumes significant context. These articles may use jargon without explanation, reference obscure concepts, or present ideas in a very terse manner. You might be able to extract value, but it requires effort and potentially external research.

• 3 - Specialized/Expert audience: Articles written for readers with domain expertise. These assume familiarity with technical terminology, concepts, and background knowledge in a specific field (e.g., machine learning, software architecture, AGI research). The writing is clear if you have the prerequisite knowledge.

• 5 - General audience: Articles written to be accessible to anyone with general reading ability. These explain concepts from first principles, define technical terms when used, and don't assume specialized background knowledge. They're structured for easy consumption.

Purpose

The readability index serves several purposes:

1. Reader efficiency: Helps readers quickly determine if an article matches their current context and expertise level before investing time in reading it.

2. Content discovery: Makes it easier to filter or search for articles at the appropriate level - whether you want deep technical content or accessible introductions.

3. Author awareness: Forces me to be conscious about my target audience when writing, which can improve clarity and focus.

4. Archive navigation: As this blog contains a mix of polished articles and personal research notes, the index helps distinguish between content types.

How it's used

This index is subjective and represents my assessment at the time of writing. Your mileage may vary - what I consider a "3" might be a "5" for experts in that field or a "1" for beginners.

Why not a continuous 0-5 scale?

You might notice the scale uses discrete values (0, 1, 3, 5) rather than every integer from 0 to 5. This is intentional:

• 2 would fall between "cryptic" and "specialized" - a fuzzy middle ground that's hard to define
• 4 would be between "specialized" and "general" - again, unclear distinction

The four-point scale provides enough granularity to be useful without creating artificial precision. If an article truly feels intermediate, I'd likely rate it at the lower level (1 or 3) since it's better to underpromise and overdeliver on accessibility.

Relationship to article status

The readability index is independent of the article's status field:

• status: draft - Article is incomplete or actively being written
• status: in progress - Article is being updated and refined
• status: finished - Article is complete and unlikely to be revised

An article can be status: finished with readability: 0 (polished personal notes) or status: draft with readability: 5 (an in-progress accessible introduction). They measure different dimensions of the content.

Evolution

Like any other metadata on this blog, readability ratings may change over time as I revisit articles or as my sense of what constitutes each level evolves. The index is a tool for navigation, not a rigid categorization system.

The lab called it the Repository.

Time was not a river. It was a commit graph.

Mara’s console showed history as hashes and arrows. Every moment a node. Every decision a branch. The past was immutable. The future was a working tree full of untracked files.

She did not travel backward. She checked out.

git checkout -b stop-war a1f3c9e

The world recompiled around her. Same initial state. Same variables. Different branch name. In this timeline Hitler was still a student. Mara changed one small file. A rejected application. She committed and returned.

git checkout main

Nothing changed. Of course not. Main was untouched. The war still existed. The scars still matched their hashes.

People kept asking why she could not fix history. She explained patiently. You never fix history. You fork it.

Each jump created divergence. Entropy grew like unmerged branches. The Repository ballooned. Infinite timelines. Infinite storage. Garbage collection impossible. Nothing was truly unused.

One day she found a branch tagged by someone else.

origin/hope

No author. No timestamp. The diff was small. Fewer deaths. Slower weapons. More pauses between commits.

Mara did not merge it. Merges caused conflicts. Merges caused paradoxes.

She rebased.

She replayed the present onto hope. One commit at a time. Carefully resolving conflicts. Choosing better defaults.

When she finished, the graph looked cleaner. Still complex. Still branching. But survivable.

She pushed.

Somewhere, someone typed their first commit message.

“Initial commit.”

Dr. Sarah Chen stared at her terminal, the familiar green text glowing in the darkened lab.

$ git log --all --graph --oneline
* a3f9b2c (HEAD -> main) Fix climate models
| * 7c8d1e4 (origin/2157) Prevent asteroid impact
|/
* 2b4a8f3 Initial timeline

"Three timelines," she muttered. "And they're diverging."

The Temporal Version Control System had seemed like humanity's salvation. Jump to any point in history, create a branch, make changes, then merge back. Fix mistakes. Optimize outcomes. What could go wrong?

Everything, apparently.

Sarah's colleague Marcus rushed in. "We've got a problem. The 2157 branch where we prevented the asteroid? It created a merge conflict with main."

"Show me."

$ git merge origin/2157
Auto-merging timeline.dat
CONFLICT (content): Merge conflict in timeline.dat
Automatic merge failed; fix conflicts and then commit the result.

Sarah pulled up the diff:

<<<<<<< HEAD
2089: Global climate stabilized, population 9.2B
2157: Thriving lunar colonies established
=======
2089: Asteroid prevention tech drives new space race
2157: Mars terraforming 40% complete, population 12.7B
>>>>>>> origin/2157

"They're both real," Marcus whispered. "Both timelines exist simultaneously until we resolve the conflict."

Sarah nodded slowly. Quantum superposition at a temporal scale. The universe itself refusing to compile until they chose which future to keep-and which to discard.

Her fingers hovered over the keyboard. One timeline solved climate change through sacrifice and discipline. The other achieved it through desperate innovation sparked by near-extinction.

"What if," she said, "we don't choose?"

"You can't leave a merge conflict unresolved. The timeline will remain in an unstable state-"

"Or we git rebase everything onto a new branch. Cherry-pick the best commits from each timeline."

Marcus's eyes widened. "You want to rewrite history itself."

"We already are. We've just been doing it badly." Sarah started typing:

$ git checkout -b unified
$ git cherry-pick 7c8d1e4  # Asteroid prevention tech
$ git cherry-pick a3f9b2c  # Climate stability

The lab hummed. Reality flickered.

When the command completed, Sarah checked the log:

* e9f2a1b (HEAD -> unified) Climate models + prevention tech
* 2b4a8f3 Initial timeline

Clean. Linear. Optimal.

"Git push --force?" Marcus asked nervously.

Sarah smiled. "Git push --force."

She hit enter.

The universe accepted the merge.