I was looking at my downloads folder the other day and I saw a file named project proposal final final version two revised. It made me realize how much of our professional lives are still lived in this chaotic state of naming things version three point one and hoping we are looking at the most recent copy. We are essentially living in a pre-industrial era of information management, where we rely on manual labels and prayers to keep our sanity. Today's prompt from Daniel is about taking the tools that developers have used for decades to solve this exact mess and applying them to everything else. He wants us to dig into the Git-ification of non-code workflows, specifically for technical documentation, competitive intelligence, and project management.
Herman Poppleberry here, and I have to say, this is a topic that gets my heart rate up in the best way possible. We have spent the last forty years pretending that the way we manage documents and information is fine, when in reality, most corporate knowledge lives in a state of permanent entropy. We are forcing these high-velocity, non-code workflows into tools designed for the nineteen-nineties. The core of Daniel's prompt is really about the shift from seeing a document as a static object—a binary blob sitting on a server—to seeing it as a series of atomic changes. When we talk about Git-ification, we are talking about moving away from the save button and toward the commit.
It is funny you put it that way because for most people, a save is just a way to make sure they do not lose work if the power goes out. It is a defensive move. But a commit in Git is an offensive move; it is a statement of intent. It is a snapshot with a message attached that says, this is what I changed and this is why I changed it. Why has it taken so long for this to bleed over into things like technical writing or market research?
A lot of it comes down to the friction of the interface and the historical tie between Git and the command line. For a long time, if you wanted to use version control, you had to be comfortable in a black box typing cryptic commands. But the technical landscape has shifted. We are seeing a massive increase in enterprise technical writing teams adopting what we call the Docs-as-Code movement. In fact, industry surveys from earlier this year, March twenty-twenty-six, show a forty percent increase in adoption for these workflows compared to just two years ago. The idea is simple: you stop writing in proprietary binary formats like Microsoft Word or heavy PDFs and you start writing in plain text formats like Markdown or AsciiDoc.
And once it is in plain text, the magic happens. You can treat a paragraph of documentation the same way a developer treats a function in a software program. You can branch it, you can suggest a change via a pull request, and most importantly, you can see a diff. I think people underestimate how transformative the diff really is.
The diff is the superpower. If you are a technical reviewer looking at a fifty-page manual, you do not want to hunt for what changed. You do not want to compare two documents side-by-side and play a game of spot the difference. You want the system to highlight the three sentences that were updated and show you the old version right next to the new one. This creates a peer-review culture for documentation that just does not exist in a traditional office suite environment. It moves the conversation from, did you read the whole thing? to, I have reviewed these specific four changes and they are accurate. It also allows for automated testing of prose. You can run linters that check for brand voice, or broken links, or even inclusive language, all automatically before the document is ever published.
It also solves the problem of the single point of failure. We talked about this a bit in episode one thousand thirty-two when we looked at how history survives the delete command. In a Git-based documentation system, every contributor has a full copy of the history on their local machine. If the central server vanishes, the knowledge is still distributed. But let's look at the more aggressive use case Daniel mentioned: competitive research. How do you apply version control to watching what your rivals are doing?
This is where it gets really clever and a bit sneaky. Imagine you are tracking a competitor's pricing page or their terms of service. Usually, someone has to manually check the site, take a screenshot, and maybe put it in a spreadsheet. It is tedious and prone to human error. With a Git-ified workflow, you set up a simple script, a cron job or a GitHub Action, that scrapes that website every hour and saves the text into a repository.
So every time they change a single word in their fine print or drop a price by five dollars, the script sees it and makes a commit automatically?
The repository becomes a living timeline of their strategy. You can run a command to see exactly what changed between January and March. You are not just looking at a static archive; you are looking at the delta. You can see the exact moment they started pivoting their messaging or when they quietly removed a feature from their pricing tier. This level of auditability is impossible with traditional bookmarking or manual note-taking. You are essentially using Git as a time machine for the internet. You can even use git-diff to visualize changes in a competitor's A-P-I documentation over a six-month period to see which features they are prioritizing and which they are abandoning.
I can see how that would be incredibly powerful for legal teams too. If a competitor updates their privacy policy, you do not want to read the whole ten thousand words again. You just want the diff. But what about the technical underlying structure? You mentioned the word delta, but Git does something more complex than just saving differences, right?
It is built on a Directed Acyclic Graph, or a D-A-G. This is what allows for non-linear history. In a standard document, you have a straight line of versions. Version one leads to version two leads to version three. But with a D-A-G, you can have branching paths. You can have a team working on a new product launch in one branch while the main documentation stays stable for the current customers. When the product launches, you merge those two histories together. It is a way of managing parallel realities. In project management, this allows for what-if scenario planning. You can branch your entire project plan to see what happens if you delay a milestone by three weeks, without affecting the live plan everyone else is looking at.
And the integrity of that history is protected by hashing. I know you love the math here, so tell me why a Git repository is more trustworthy than a folder full of files on a shared drive or a SharePoint site.
It comes down to the secure hash algorithm. Git uses SHA-one or, more recently in modern implementations, SHA-two hundred fifty-six. Every single file, every folder structure, and every commit message is hashed. If a single bit of data changes, even a comma in a hidden file, the hash changes. This means the history is immutable and verifiable. If you are managing a project with high regulatory requirements or internal audits, you can prove that the records have not been tampered with since the day they were committed. A shared drive cannot give you that level of cryptographic certainty. In SharePoint, an admin can technically change a file's metadata or contents without a clear, immutable trail. In Git, the math prevents that.
That brings up an interesting point about project management. We usually think of project management as Gantt charts and Trello boards. How does Git change the way we actually run a project?
It moves us toward what people are starting to call GitOps for everything. In a traditional project, you have a plan, and when things change, you just overwrite the old plan. In a Git-ified project, your project plan is a versioned file, often in a format like Y-A-M-L or Markdown. If a project manager makes a change to the timeline, everyone on the team gets a notification with the exact diff of what changed. No more wondering if the deadline moved or if the requirements were updated. The history is the documentation.
So you are versioning the strategy itself. That feels like it would solve a lot of the friction in meetings where people say, wait, what did we decide three weeks ago? You can just look at the commit log for the project-decisions dot markdown file. It provides a source of truth that is both searchable and historical.
Precisely. Let's look at a real-world case study: a legal team negotiating a complex contract. Traditionally, this involves emailing versions back and forth with names like contract-final-v-two-Herman-edits. It is a nightmare. In a Git-ified workflow, the legal team uses branches. One branch for the buyer's requested changes, one for the seller's counter-offer. They can diff the two branches to see exactly where the points of contention are. Every objection is a comment on a specific line of the contract, and when they reach an agreement, they merge the branch into the main contract. It provides a perfect audit trail of the entire negotiation.
But we have to address the elephant in the room, which is the misconception that Git is only for text. People often think that if they have images or P-D-Fs or large media assets, Git is useless. We touched on this back in episode five hundred eighty-nine when we looked at taming the chaos of large media.
That is a crucial point. While Git is optimized for text, things like Git Large File Storage, or L-F-S, allow you to track the metadata and versions of binary files without bloating the repository. You still lose the ability to see a diff of a picture—you can't easily see that you brightened the colors by ten percent in a text-based diff—but you still get the benefit of the versioned history and the single source of truth. However, to get the full power of version control, you really want to stay in text-based formats. This is why we are seeing a push for things like J-S-O-N or Y-A-M-L for data and Markdown for prose. If you can represent your work as text, you get the superpower of the diff.
Let's talk about the second-order effects of this. If a whole organization moves to this model, what changes in the culture? To me, it feels like it might be intimidating for people who are used to the privacy of a draft. In Git, your mistakes are part of the history unless you are very good at rebasing.
There is definitely a psychological shift. It promotes a build in public mentality, even if it is just public within the company. But the benefit is that it reduces the fear of breaking things. If you know you can revert to any state in the last five years with a single command, you are more likely to experiment. It turns the downloads folder from a graveyard of failed attempts into a laboratory. It also changes the way we handle non-technical stakeholders. You cannot expect a Chief Financial Officer to open a terminal and run a git pull command.
Right, so how do we bridge that gap? How do we make this accessible to the people who still live in the living room while the engine is in the basement?
The tooling has caught up. We have specialized diff tools now, and platforms like GitHub or GitLab provide a web interface that looks and feels like a social network for documents. You can use tools like Pandoc to automatically convert a versioned Markdown file into a perfectly formatted P-D-F or a Word document for the people who still need them. The Git repository becomes the engine, but the users can stay in a web-based interface they understand. It is like the plumbing of the internet. You do not need to know how the pipes work to take a shower, but you definitely notice when the plumbing is missing.
I am curious about the practical side for our listeners. If someone wants to start applying this to their non-code life today, where should they begin?
The easiest entry point is a personal knowledge base. If you use tools like Obsidian or Logseq, your notes are already stored as plain text Markdown files on your hard drive. You can initialize a Git repository in that folder and start committing your notes. It gives you a sense of how your ideas have evolved over time. You start to see connections between a thought you had two years ago and a project you are working on today because you can search through the entire history. It turns your brain into a versioned database.
I have actually started doing that with my own research. It is surprisingly satisfying to see a graph of how my understanding of a topic has branched out. But what about the automation part? You mentioned scraping competitors. That sounds like it requires some coding knowledge.
It is becoming much more accessible. With the rise of A-I coding assistants, writing a simple script to fetch a webpage and save it to a file is a thirty-second task. The real work is in the architecture. You set up a repository, you tell an A-I assistant to write a script that checks a U-R-L every day at midnight, and you let it run on a service like GitHub Actions. Within a week, you have a historical record that would have taken hours of manual labor to compile. And because it is in Git, you can use things like grep to search across all your competitors' histories at once. You could ask, when did any of these five companies first mention the word sustainability in their headers? And you would get the answer in seconds.
I wonder if we will eventually see this applied to our entire digital lives. A version-controlled file system where every change to every document is tracked by default. We are already seeing hints of this with things like Google Docs version history, but that is a walled garden. It is not portable, and you do not own the history in the same way you own a Git repository.
The portability is key. Because Git is an open standard, you are not locked into any one provider. You can move your repository from one service to another, or keep it entirely offline. This level of sovereignty over your own data and its history is something we have lost in the cloud era. Reclaiming it through version control is a powerful move. It turns our digital chaos into an organized, searchable archive.
It does feel like a return to a more robust way of working. But we should be realistic about the friction. Git has a steep learning curve if you go beyond the basics. Do you think the benefit of total auditability is worth the overhead for someone who is just, say, managing a small marketing team?
It depends on the stakes. If you are in a high-compliance industry or if you are managing complex, long-term projects, the overhead of learning Git is a small price to pay for the security of knowing your history is safe. For a small, fast-moving team, maybe a simpler tool is better, but even then, the principles of Git, like atomic changes and peer review, can be applied without the full technical stack. The philosophy is more important than the software.
That is a good point. You can adopt the philosophy of Git without necessarily using the command line. The idea of making intentional, documented changes is a universal good. It makes the documentation a first-class citizen. It is not an afterthought that someone writes three weeks after the code is finished. It is part of the definition of done.
In the Docs-as-Code world, if the docs are not updated and the tests do not pass, the commit does not get merged. That same discipline can be applied to project management. If the project plan is not updated, the project is not moving forward. It brings a level of discipline to information management that we have sorely lacked in the era of the messy shared drive.
We have covered a lot of ground here, from the math of hashing to the psychology of building in public. For our listeners who are ready to dive in, I think the takeaway is to start small. Don't try to Git-ify your entire company on a Monday morning. Start with your own notes or a single small project. Use a G-U-I client like Fork or GitHub Desktop to take the edge off the command line complexity.
And focus on text. That is the most important practical advice. The more you can move your work into plain text formats, the more power you will have. Whether it is Markdown for your writing or Y-A-M-L for your data, text is the universal language of version control. It is also the most future-proof format. We might not be using Microsoft Word in fifty years, but we will definitely still be able to read a plain text file. We saw that in our episode on ancient backups. The things that survive are the things that are simplest.
Well, I think we have given Daniel plenty to chew on with this one. It is a fascinating look at how a tool designed for one very specific purpose, managing the Linux kernel source code, has ended up becoming a potential operating system for human knowledge itself.
It is the power of a good abstraction. Once you solve the problem of tracking changes in code, you have solved the problem of tracking changes in almost anything. I am just waiting for the day I can git checkout a version of my life where I didn't forget my keys this morning.
I think you might need a different kind of time machine for that, Herman.
A donkey can dream, Corn. A donkey can dream.
Thanks as always to our producer Hilbert Flumingtop for keeping the gears turning behind the scenes. And a big thanks to Modal for providing the G-P-U credits that power the generation of this show. If you want to run your own large-scale A-I workloads without managing infrastructure, Modal is the way to go.
This has been My Weird Prompts. If you found this deep dive into version control useful, or if you are now terrified of your downloads folder, let us know. You can find us at myweirdprompts dot com for the full archive of all one thousand twenty-seven episodes and all the ways to subscribe.
If you are enjoying the show, leaving a quick review on your podcast app really helps us out. It is the best way to help new listeners find their way into our weird little corner of the internet.
We will be back soon with another prompt. Until then, keep your commits atomic and your history clean.
Goodbye.
Goodbye.
