Git Is About History

One of the greatest frustrations in digital writing is deciding what to do with old versions.

Almost everyone has created files that look something like this:

• article-final.md
• article-final2.md
• article-final-revised.md
• article-final-revised-final.md
• article-final-real-final.md

The computer faithfully stores every copy.

The human eventually forgets which one is the correct version.

Git solves this problem by recording the history instead of creating endless copies.

Each meaningful change becomes a commit—a snapshot of your work accompanied by a short explanation of what changed.

Instead of asking yourself which file is the newest, you simply ask Git.

It remembers.

Writing Is Revision

Good writing is rarely produced in one sitting.

We remove paragraphs.

We rewrite introductions.

We experiment with different titles.

Sometimes we discover that yesterday’s version was actually better than today’s.

Without version control, those older ideas disappear.

With Git, they never truly vanish.

Every revision becomes part of the story of the document.

You gain the confidence to experiment because you know that nothing important is permanently lost.

Ironically, version control encourages creativity by making failure inexpensive.

Your Configuration Files Are Also Writing

Yesterday we explored the joy of dotfiles.

Configuration files are simply another form of writing.

They describe how your computer should behave.

Whether it is your shell prompt, your Vim settings, your terminal emulator, your window manager, or your Git configuration itself, these files represent hundreds of small decisions accumulated over years.

Losing them often feels like losing a part of your workflow.

Git gives those decisions a memory.

Every improvement becomes documented.

Every mistake becomes reversible.

Every experiment becomes safe.

After enough years, your repository becomes a diary of how your computing environment evolved.

Git Makes Computers Reproducible

One of the great promises of plain text is reproducibility.

If your work lives in text files, then it can be copied, backed up, synchronized, searched, and understood almost anywhere.

Git extends this philosophy.

Instead of merely backing up your files, it preserves their evolution.

A new laptop no longer means beginning from scratch.

A system reinstall becomes far less intimidating.

You simply retrieve your repository and your carefully crafted environment begins to reappear.

Your computer starts to feel less like a collection of installed software and more like a project that you maintain.

Collaboration Without Chaos

Many textsmiths eventually collaborate.

Perhaps you write documentation.

Perhaps you maintain a knowledge base.

Perhaps several people edit the same website.

Without version control, collaboration often becomes an exchange of files through email or messaging applications.

Conflicts become difficult to resolve.

Nobody knows whose copy is authoritative.

Git provides a shared history.

Everyone contributes to the same project.

Changes are recorded.

Authors are identified.

Mistakes can be undone.

Even when working alone, these capabilities are surprisingly reassuring.

Git Rewards Small Improvements

One of Git’s most valuable lessons has little to do with software.

It teaches incremental progress.

Instead of waiting until everything is perfect, you save meaningful milestones along the way.

Each commit becomes a promise:

“This version works.”

Weeks later, you can retrace your thinking one step at a time.

The history tells the story of how an idea matured.

For a textsmith, that history is often as valuable as the finished document itself.

You Don’t Need to Become a Software Engineer

Learning Git does not require becoming a programmer.

Many textsmiths use only a surprisingly small collection of commands:

• initialize a repository;
• check what changed;
• save a snapshot;
• review history; and
• synchronize with a remote backup.

That modest knowledge already provides enormous value.

Everything else can be learned gradually as your projects become more sophisticated.

Git rewards curiosity rather than demanding mastery from the beginning.

A Tool Worth Carrying

Textsmiths already understand the value of plain text.

We trust it because it lasts.

We value it because it is portable.

We prefer it because it remains understandable decades later.

Git complements those same ideals.

It preserves not only our documents but also the journey that produced them.

If plain text is the foundation of digital craftsmanship, then Git is the archive that protects it.

Every textsmith should learn to write.

Every textsmith should learn to revise.

And every textsmith should learn to preserve that revision history.

Git makes all three part of the same craft.

More Than Hidden Files

On Unix-like systems, files whose names begin with a period are hidden by default. These include familiar names like:

• .bashrc
• .vimrc
• .gitconfig
• .profile

Collectively, people often call these dotfiles.

The name sounds rather unremarkable.

In reality, they represent something much more interesting: they describe your computer.

Not the hardware.

Not the operating system.

Your environment.

Your editor behaves the way it does because of them.

Your shell knows your aliases because of them.

Git knows your preferred editor because of them.

Your prompt, your keyboard shortcuts, your plugins, your themes, your workflow—all of it lives in ordinary text files.

They become a written description of how you like your computer to behave.

Configuration Becomes Knowledge

Once configuration is stored as text, something wonderful happens.

Text can be read.

Text can be searched.

Text can be documented.

Text can be version controlled.

Text can be copied.

Text can be shared.

Instead of being trapped inside one particular machine, your computing environment becomes knowledge.

It becomes portable.

My Computer Became Reproducible

Around 2019, I started maintaining my dotfiles properly.

Seven years later, I still use essentially the same Vim configuration.

My shell setup has remained remarkably consistent.

In fact, I have a directory called .rc that is sourced from my ~/.bashrc. Over the years I have occasionally added a new file, removed an obsolete alias, or adjusted a setting for new software.

Otherwise…

It has simply kept working.

The amusing part is that I have almost forgotten how I originally built it.

That sounds like a bad thing until you realize what it actually means.

I don’t have to remember.

The knowledge has already been written down.

A New Computer Is No Longer a Project

There was a time when getting a new computer meant spending an afternoon rebuilding my environment.

Which aliases had I forgotten?

How did I configure Vim?

What plugins did I use?

Which environment variables mattered?

What did my prompt look like?

Every new machine felt like starting over.

Today, the process is almost boring.

As long as I have a network connection, I clone my bare Git repository containing my dotfiles.

Less than a minute later, I am largely back in business.

My editor behaves correctly.

My shell behaves correctly.

My shortcuts are there.

My workflow feels familiar.

The machine may be new.

The environment is not.

Version Control Changes Everything

Years ago, backing up configuration usually meant copying files onto another disk and hoping you remembered everything.

Git changed that.

Every change becomes part of a history.

If I experiment with a configuration that turns out to be a terrible idea, I can simply roll it back.

If I discover a useful improvement, it becomes part of the permanent record.

My configuration evolves in small, understandable steps.

That is exactly how software evolves.

Why shouldn’t my computing environment evolve the same way?

The Opposite of Starting From Scratch

One thing I never enjoyed about registry-based systems was that customizations often felt tied to a particular installation.

You could certainly back up an entire machine.

You could export sections of the registry.

But neither felt like carrying your environment with you.

Dotfiles turn that idea inside out.

Instead of backing up an entire operating system, you preserve the parts that actually express your preferences.

The operating system becomes replaceable.

Your workflow does not.

Documentation You Write Without Realizing

There is another benefit that is easy to overlook.

Every configuration file explains something.

Every alias has a purpose.

Every function tells a small story.

Every comment reminds your future self why a decision was made.

Over time, your dotfiles become one of the most honest forms of technical documentation you will ever write.

Not because you intended to write documentation.

Because you intended to solve problems.

The documentation emerged naturally.

Plain Text Wins Again

One of the recurring themes on this blog is that plain text has surprising staying power.

Dotfiles are another example.

They are ordinary text files.

No special editor is required.

No proprietary format needs decoding.

No vendor controls how they are interpreted.

They can be edited with Vim, Emacs, Nano, Notepad, or any editor you happen to have available.

They survive operating system upgrades.

They survive hardware replacements.

They survive decades.

Reproducibility Is Freedom

Software developers often speak about reproducible builds.

Scientists care about reproducible experiments.

I think ordinary computer users deserve reproducible computers.

Your machine should not be a collection of lucky accidents accumulated over several years.

It should be something you can describe.

Something you can rebuild.

Something you can understand.

Something you can carry with you.

That is the real joy of dotfiles.

They remind us that our computers are not magical objects that gradually drift into a usable state.

They are systems whose behavior can be written down, preserved, and recreated.

And once your computing environment becomes reproducible, a new computer stops feeling like the beginning of a long weekend.

It becomes just another machine waiting to read your text.

The Registry Never Felt Like Home

Long before I switched to Linux, I spent years using Windows. Like many curious users, I occasionally found myself editing the Windows Registry.

It was never a pleasant experience.

The Registry always felt like wandering through an enormous underground warehouse where every shelf contained thousands of unlabeled boxes. Somewhere inside was the one value you needed to change—but if you touched the wrong thing, you could spend the afternoon repairing your system.

The Registry wasn’t merely complicated.

It was opaque.

Every setting felt detached from the application it belonged to. Programs scattered their configuration across countless branches. Exporting settings meant exporting binary blobs. Backing things up required specialized tools. Understanding what a value meant often required searching obscure forum posts written years earlier.

It was configuration by archaeology.

Then Came INI Files

Some applications chose a different path.

Instead of hiding their settings inside the Registry, they stored them beside the program in simple .ini files.

The difference was astonishing.

Open the file.

Read it.

Change a value.

Save.

Restart the application.

That was all.

Even before I understood programming, these files made intuitive sense.

theme=dark
autosave=true
fontsize=14

There was almost no mystery.

Changing the program’s behavior felt less like performing surgery and more like filling in a form.

The software explained itself.

Software That Speaks Plain Text

Looking back, I realize those tiny configuration files quietly taught me one of the most important ideas in computing.

Programs are often just functions.

Configuration files are simply the inputs.

Instead of hard-coding every behavior, software reads a file, assigns values to internal variables, and behaves accordingly.

When you write

autosave=true

you are, in effect, telling the program:

“Use this value instead of the default.”

Nothing magical happened.

The software did exactly what you asked.

The configuration became a conversation between the user and the program.

Linux Made the Idea Universal

When I moved to Linux in 2018, this philosophy suddenly appeared everywhere.

Configuration wasn’t hidden.

It lived in files.

Some applications stored their settings in the home directory.

Others placed them neatly under ~/.config.

Desktop environments, editors, terminals, shells, media players, version control systems, and countless command-line tools all exposed their behavior through ordinary text.

Suddenly I could answer questions like:

• Why does my shell look this way?
• Why is this editor using these colors?
• Why does this shortcut exist?
• Why is this application behaving differently from yours?

The answer was almost always:

“Look at the configuration.”

That simple sentence changed the way I thought about computers.

Nothing Is Hidden

Configuration files embody one of the oldest Unix ideas:

Nothing should be mysterious if the user wants to understand it.

Want to know how your terminal starts?

Read its configuration.

Wondering where Git gets your name?

Open the configuration file.

Curious why Vim behaves differently?

Look at .vimrc.

Need to reproduce your development environment?

Copy the configuration.

The software isn’t guarding its secrets.

It’s inviting you to learn.

Configuration Is Documentation

One surprising discovery is that configuration files double as documentation.

Months later, you can return to them and immediately understand your earlier decisions.

tab-width = 4
wrap = false
spellcheck = true

These aren’t merely settings.

They’re explanations.

A well-written configuration file tells a story about how someone likes to work.

Many users even add comments describing why they chose a particular option.

# Enable line numbers because I often review logs.
linenumbers=true

The configuration becomes a notebook.

Your Computer Should Be Explainable

One reason I fell in love with plain text is that it makes computers explain themselves.

Modern software is astonishingly complex.

Operating systems manage millions of moving parts.

Applications communicate over networks.

Processors execute billions of operations every second.

That complexity is unavoidable.

But unnecessary mystery isn’t.

When a program stores its settings in a readable file, I don’t need to wonder why it’s behaving the way it is.

I can simply read the instructions I—or someone else—gave it.

Computers already perform enough magic in the silicon.

I don’t need additional magic in their configuration.

Better Than Hidden State

Plain-text configuration has many practical advantages.

It is easy to back up.

It works naturally with version control.

It can be synchronized across machines.

It can be searched with ordinary tools.

It survives software upgrades.

It can be edited using any text editor.

It can be compared line by line.

Most importantly, it remains understandable years later.

Even applications that store some information in databases often keep their user-facing configuration in plain text, separating operational data from human decisions.

That distinction matters.

Databases are excellent for storing information.

Configuration files are excellent for expressing intent.

A Philosophy, Not Just a File Format

People sometimes assume configuration files are merely a technical implementation detail.

I think they’re something much deeper.

They reflect a philosophy.

They say:

“This computer belongs to you.”

Not the operating system.

Not the application developer.

Not some hidden control panel buried beneath six menus.

You.

Your preferences live in a file you can read, understand, and change.

There is dignity in that kind of transparency.

Becoming a Textsmith

Looking back, I now realize my journey into plain text didn’t begin with Markdown.

It didn’t begin with LaTeX, Quarto, or shell scripting.

It began with opening a humble configuration file and discovering that software could explain itself.

That experience changed how I viewed computers.

Since then I’ve come to appreciate many technologies built on the same principle: markup languages, documentation systems, version control, scripting, automation, and publishing workflows.

All of them share one beautiful idea.

If something matters, write it down in plain text.

The computer will take care of the rest.

Why We Gather Around the Fire

A favourite tool is rarely just a tool.

It represents hours, months, sometimes years of learning. It becomes part of our thinking. A skilled Vim user does not merely edit text differently from an Emacs user; they often think about editing differently. Someone deeply invested in Arch Linux has a different relationship with their operating system than someone who prefers Ubuntu or Fedora.

The same is true for markup languages.

Once you’ve internalised Markdown’s elegant simplicity, you naturally appreciate its readability and portability. An AsciiDoc enthusiast values expressive power and sophisticated publishing workflows. Org Mode users see documents as living systems rather than static files.

These preferences are not accidents. They grow out of experience.

And that is a good thing.

Mastery comes from commitment. Productivity comes from familiarity. We become efficient because we stop thinking about the tool and start thinking about the work.

The campfire gives us warmth because people care deeply about what they have learned.

The Value of Friendly Wars

Healthy disagreements have always been part of technical culture.

They force us to explain why we prefer a tool rather than merely saying that we do.

They expose us to alternatives we might never have considered.

They encourage software authors to improve their projects.

Many innovations have emerged because one community looked across the fire and thought, “That’s actually a clever idea.”

The Unix world has thrived precisely because people have experimented, disagreed, borrowed ideas, and improved upon one another’s work.

Today’s “winning” feature is often yesterday’s controversial experiment.

Without passionate communities, software would evolve much more slowly.

When the Fire Escapes

A campfire is wonderful when it remains inside its circle of stones.

Left unattended, however, it can burn an entire veld.

Technical communities are no different.

Sometimes people become defenders of a cause without really understanding why the cause existed in the first place. They inherit opinions rather than forming them through experience.

Instead of learning their own tools more deeply, they spend their energy criticising someone else’s.

The discussion shifts from productivity to identity.

“I use this editor.”

becomes

“My editor makes me better than you.”

That is where the fire becomes dangerous.

Technology should serve people, not divide them.

No one ever became a better writer by mocking another person’s text editor. No administrator managed servers more effectively by ridiculing someone else’s Linux distribution. No document became clearer because its author spent an afternoon arguing about markup languages on the Internet.

Real craftsmanship happens away from the battlefield.

A Textsmith’s Perspective

Here at The Textsmith, our loyalty is not to a particular editor, operating system, or distribution.

Our loyalty is to text.

We celebrate plain text because it lasts.

We celebrate markup because it gives structure without sacrificing readability.

We celebrate tools because they help us think, write, publish, and preserve knowledge.

Whether you write Markdown in Visual Studio Code on Windows, edit AsciiDoc inside Vim on Linux, compose Org Mode files in Emacs, or use another workflow entirely, you are welcome around this fire.

(For the record, the editor of this blog is thoroughly steeped in Linux—but that is a personal preference, not a membership requirement.)

What matters is not the badge on your laptop.

What matters is whether your tools help you create.

Keep the Fire Burning

Every camper enjoys a different fire.

Some burn hardwood.

Some prefer charcoal.

Some cook with gas.

The wise camper does not walk around extinguishing everyone else’s fire.

Instead, they exchange stories.

They borrow recipes.

They share techniques.

They learn.

The best technical communities have always worked this way. Beginners find mentors. Experts remain curious. Ideas travel from one campfire to another, improving everyone along the way.

That is the kind of community worth building.

So enjoy the debates. Defend your favourite editor if you must. Tell us why your markup language makes writing more enjoyable. Explain why your Linux distribution fits your workflow perfectly.

Just remember that the purpose of the campfire is to provide warmth—not to burn the veld.

If we can keep the fire where it belongs, there will always be room for another chair around it.

The Formatting Problem Nobody Wanted to Solve

Back in 2004, web designer John Gruber teamed up with the late Aaron Swartz to solve an irritating problem.

Writing HTML was tedious.

Even simple formatting required walls of tags, nested elements, and syntax that interrupted the act of writing. The pair wanted something simpler—a way to write naturally while still producing clean HTML.

Markdown was their answer.

Its brilliance wasn’t technical sophistication. It was restraint.

A heading became a hash symbol.

A list became a dash.

Bold text required only a pair of asterisks.

The syntax practically disappeared.

They weren’t trying to invent a new publishing standard.

They certainly weren’t trying to replace Microsoft Word.

Yet that’s exactly where history has carried their little experiment.

The Internet Chose Markdown Before Anyone Noticed

Unlike many technologies, Markdown wasn’t adopted because a corporation declared it a standard.

Developers simply kept choosing it.

GitHub embraced it because software projects needed documentation that lived alongside code.

Stack Overflow used it because programmers needed readable questions and answers.

Reddit adopted it because millions of users wanted lightweight formatting without a WYSIWYG editor getting in the way.

Then came static site generators, documentation systems, note-taking applications, developer portals, knowledge bases, and eventually AI writing tools.

Markdown spread because every new platform discovered the same thing: plain text is astonishingly hard to break.

Meanwhile, Word documents accumulated corrupted styles, mysterious spacing, incompatible templates, and formatting gremlins that every office worker has fought at least once.

One format encouraged collaboration.

The other often encouraged swearing.

The Real Lesson Was Never About Developers

For years it was easy to dismiss Markdown as a tool for programmers.

That stereotype no longer survives contact with reality.

Journalists write in Markdown.

Academics draft papers in Markdown.

Novelists use Markdown.

Technical writers practically live inside it.

Even governments and research institutions increasingly publish documentation that begins life as plain text before being transformed into polished websites, PDFs, and reports.

The reason isn’t that these people suddenly became programmers.

It’s that they discovered something developers had known all along.

Formatting is rarely the important part of writing.

Thinking is.

Markdown removes just enough friction to let writers stay focused on ideas instead of wrestling with fonts, indentation, numbering schemes, and toolbar buttons.

That’s an astonishingly difficult balance to achieve.

LibreOffice Just Said the Quiet Part Out Loud

This is why LibreOffice’s new Markdown export matters.

On paper, it’s just another file format.

In reality, it’s an admission.

Office suites have spent decades treating richly formatted documents as the primary product.

The assumption has always been simple: first you create the document, then everything else follows.

But today’s writing doesn’t stay inside a single application.

A project proposal becomes a web page.

Meeting notes become wiki entries.

Documentation becomes a knowledge base.

AI assistants ingest text.

Publishing pipelines transform the same content into websites, PDFs, mobile apps, newsletters, and printed manuals.

The document is no longer the destination.

It’s merely one possible output.

That’s a profound philosophical shift.

When an office suite exports Markdown, it’s effectively acknowledging that its own native document format is no longer the centre of the universe.

The Office Suite Is Facing Its “JPEG Moment”

Photography offers an interesting parallel.

Once upon a time, every camera manufacturer had proprietary RAW formats.

Professionals still use them.

But for everyday life, JPEG became the universal currency because every device understood it.

No one cared which software created the image.

They cared that everyone could open it.

Markdown is becoming the JPEG of writing.

Not because it’s the richest format.

Quite the opposite.

It wins because almost everything can read it.

Every editor.

Every operating system.

Every version-control system.

Every AI assistant.

Every publishing workflow.

Every decade.

Future-Proofing Is Suddenly a Big Deal Again

Here’s an uncomfortable thought.

How many documents on your computer will still open perfectly fifty years from now?

Not “with some formatting issues.”

Not “after converting them.”

Perfectly.

The answer is probably fewer than you’d like.

Software dies.

Companies disappear.

File formats evolve.

Compatibility layers eventually vanish.

Plain text, however, has outlived almost every revolution in computing.

Mainframes.

Personal computers.

DOS.

Windows.

macOS.

Linux.

The web.

The cloud.

Mobile computing.

AI.

Through all of it, text files remained readable.

A Markdown document created today has a surprisingly good chance of being completely understandable in 2076—even if Markdown itself somehow disappears.

Because underneath the syntax lies something wonderfully boring.

Text.

And text has proven to be one of humanity’s most durable technologies.

AI May Finish What Developers Started

There’s another reason Markdown’s momentum feels unstoppable.

Artificial intelligence.

Large language models don’t care about your carefully chosen fonts.

They don’t appreciate decorative page borders or intricate Word styles.

They care about structure.

Headings.

Lists.

Code blocks.

Tables.

Semantic meaning.

Markdown gives AI exactly what it needs while remaining perfectly readable to humans.

That makes it one of the rare formats that serves both people and machines equally well.

As AI becomes a routine part of writing, editing, publishing, and collaboration, Markdown isn’t becoming less relevant.

It’s becoming infrastructure.

The Quiet Winner

Markdown never defeated Microsoft Word.

It didn’t have to.

Instead, it quietly changed the assumptions about what writing should be.

Write first.

Style later.

Keep your content portable.

Separate ideas from presentation.

Trust open formats over proprietary ones.

These principles sounded almost radical in 2004.

Today they feel inevitable.

LibreOffice’s “Save As Markdown” option won’t make headlines outside technology circles.

But history often hides inside seemingly insignificant features.

Sometimes the biggest shifts don’t arrive with fireworks.

Sometimes they arrive as a new entry in the File → Save As menu.

And years later, we look back and realize the revolution had already happened.

The Crisis of Modern Computing

We have traded our digital sovereignty for convenience. Modern software has become a “black box”—bloated, extractive, and fragile. When the interface changes, your muscle memory is erased. When the server goes down, your tools vanish.

Our Reclamation

Being a Textsmith means returning to the terminal. It means mastering the Unix Trinity (grep, sed, awk) to treat data as a craft. It is about:

• Sovereignty: Owning your tools and your data through plaintext.
• Stability: Using interfaces that haven’t changed since the 70s and won’t change tomorrow.
• Accessibility: Recognizing that the command line is the most inclusive environment ever built—where logic, not layout, is king.

Here, we hammer out the noise until only the elegant power of the terminal remains.