Coder Legion - Recent posts tagged git

No, Git Isn't Dead. Anthropic's Robots Just Needed a Bigger One.

Fri, 30 Oct 2026 07:44:39 +0000

The viral version says Git died in 2026.

The real story is funnier: seven humans spent five months building a version control system so their AI could keep merging 30,000 changes a day and it works by banning the two features Git is most famous for.

A post went around this week with the energy of a tabloid that just found out your marriage is over before you did. "Git is DEAD in 2026?" Two screaming-face emojis.

Anthropic has replaced Git with its own system called Scion, the robots write too much code, Git simply couldn't keep up, pour one out for the little distributed version control system that could.

And here's the thing that ruins a perfectly good funeral: the story is basically true. Anthropic did build an in-house source control system called Scion. They did move their internal monorepo off Git.

They are, by their own numbers, merging more than 30,000 code changes a day. I read their actual engineering write-up, because somebody has to, and it's a genuinely great piece of engineering.

It's also not a eulogy for Git. It's a note from the office saying the robots need a bigger desk. Let me show you the difference, because the difference is the whole joke.

The clickbait says "Git is dead." The footnotes say "please do not try this at home."

Here's the first thing the viral version conveniently loses. Anthropic goes out of its way to say Scion is not for everyone, is built only for one absurd situation, and is not going to be released.
This is the software equivalent of a Formula 1 team explaining that yes, the car does 370 km/h, and no, you cannot drive it to Big Bazaar.

So Git isn't dead. Git is fine. Git is running on your laptop right now, serenely, the way it has for twenty years, handling your eleven commits a week without filing a complaint.
What actually happened is narrower and far more interesting: one company hit a scale so ridiculous that a core assumption of Git stopped being free, and they had to pay to make it go away.

That assumption is the one every Git tutorial sells as the feature.

The feature that became the bill
Git is decentralized. Everyone who clones the repo gets the entire repo - every file, every branch, all of history, the whole cathedral - on their own machine. In 2005 this was revolutionary and correct.

It's why your internet going out doesn't stop you from committing. It's the thing we all fled Subversion and Perforce to get.

Now put a number on "the entire repo" at Anthropic scale. Their main branch history is pushing 100 GB. A compressed working copy is over 25 GB. And they run roughly 25 million CI checkouts a day. Do the naive multiplication and you get an estimate of more than 600 petabytes of Git traffic. Daily. To check out code.

Image: 100 GB history × 25M checkouts/day = 600 PB Press enter or click to view image in full size
Sit with the comedy of that. The beautiful, democratic idea - everybody gets a full copy! - is wonderful right up until your contributors are a swarm of always-online machines that don't need a full copy, don't go on holiday, and want to clone the cathedral every eight seconds. At that point "everybody gets everything" stops being empowerment and starts being a DDoS you're running against yourself, on purpose, with a straight face.

At peak, Anthropic was babysitting several hundred Git mirrors just to survive its own enthusiasm.
The robots didn't kill Git. The robots just took the one thing we loved about Git - you always have the whole thing - and used it ten million times a day until it showed us the bill.

Scion, or: we have reinvented Perforce and we feel great about it
So what did seven engineers build over five months? Reader, they went back to the office.

Scion is centralized. The authoritative servers are backed by Google's Spanner and cloud storage. Clients keep a small bounded cache. Most CI jobs don't even hold a local copy of the repo - they just ask the server over an API, like a civilised person ordering off a menu instead of being handed the entire kitchen.

Twenty years of the industry sprinting away from centralized version control, and the most advanced AI lab on Earth looked at its robot-generated code tsunami and sprinted straight back, yelling "it's fine, it's different when WE do it."

And - annoyingly - it is different when they do it. The wheel of history is round for a reason.
But here's my favourite detail, the one I want cross-stitched on a pillow. In Scion, branches and tags are discouraged.

Read that again. They built a version control system whose official guidance is to go easy on the two features that, for most of us, ARE version control. The reasoning is airtight - branches and tags are global state every server has to agree on, and global agreement is exactly the thing that doesn't scale when you're content-addressing immutable changesets across three tiers of cache.

But stripped of the justification, the sentence is pure deadpan poetry: welcome to our new version control system, please try not to control any versions.
The rest is seriously elegant, and I mean that with no snark left over. Commits are "changesets" that store only what changed. Everything is content-addressed and immutable, so any cache or server can answer a request without phoning a friend.

Checkouts are sparse and virtualized - a job pulls only the files it actually reads. Three tiers: a daemon on every node, regional caches, authoritative servers, each reportedly landing a cache hit rate above 99%. The payoff Anthropic reports: 200× less CPU and memory than the old mirror fleet, checkouts that went from minutes to seconds, and 25% of CI capacity handed back like finding money in a coat.

The part that should make every architect a little uneasy

Here's the detail the hot-takes skip, and it's the one I can't stop poking. Claude wrote most of Scion. The AI wrote the version control system that exists because the AI writes too much code for the old version control system.

That's not a dunk. It's an ouroboros, and it's genuinely where we are: the tooling layer is now being rebuilt, in real time, by the thing that broke the tooling layer. The system's workload created the system's solution and also authored it. Somewhere in there is a snake eating its tail while filing a pull request against itself - sorry, merging a changeset, there are no pull requests, we discourage branches.

And one more quietly radical bit: they dropped the merge queue. The old model - line up, test, then merge - stopped making sense at 30,000 a day, so Scion leans on post-merge testing and rollback instead. Merge first, find out later, roll back if it screamed. Which, if you've watched how agents write code, is also precisely how the agents write code. The tool didn't just scale to the robots. It started thinking like them.

Steal this (the you-are-not-Anthropic edition)

Architect hat on. The single most expensive mistake you can make with this story is to read "Anthropic replaced Git" and feel even a flicker of FOMO. You do not have this problem. If you build Scion for your fourteen-person team and your 400 MB repo, you have not future-proofed anything; you have cosplayed a scaling crisis and billed it to your runway.

The transferable lesson isn't centralize your VCS. It's this:

Your tool's killer feature and your tool's eventual bill are the same line item, read from different distances. "Every clone is a full repo" was the pitch and the tombstone. Audit your own stack: which beloved convenience becomes a catastrophe at 100× your current volume? That's your Git-history-is-100-GB moment, waiting.

Scale doesn't just break your performance; it breaks your assumptions. Anthropic didn't need a faster Git. They needed to delete the premise that everyone holds everything. Faster is an optimization. Deleting the premise is an architecture.

When the workload changes species, the tool has to change species. Humans and agents are not the same kind of client. Most of your tools were designed for the first and are about to be flooded by the second. That is the actual headline, and it has nothing to do with Git.

So no, Git isn't dead. Git got the highest compliment our industry gives: it was pushed until the exact shape of its one big idea became visible, and the only people it broke for were the ones running a code-generation operation the size of a small nation's power grid.

The robots didn't bury Git.
They just found the edge of the map - and politely, in a five-month sprint, drew a little more of it.

Hardik

I've spent about two decades building data and AI systems, long enough to have personally fled Perforce for Git and to now watch the industry's most advanced lab speedrun the return trip with a straight face. I write about AI in production: the parts that are genuinely new, and the parts that are just the wheel of history turning one more honest rotation.
If this made you want to go check how big your repo history actually is - follow me here, and clap a few times so Medium shows it to the next person about to build Scion for their to-do app.

Sources / further reading: Anthropic Engineering, "Creating in-house source control" (the primary source for Scion's architecture, the merge-volume figures, and the self-reported performance numbers). Coverage and analysis: DevOps.com, "Anthropic Builds Its Own Source Control After AI Agents Outgrow Git"; Crypto Briefing, "Anthropic replaces Git with custom source control system Scion"; AlphaSignal, "Anthropic Ditched Git and Built Scion After Claude Caused 12x Merge Surge." A note on the numbers: the 200× and 25% figures are Anthropic's own, measured against their previous Git mirror fleet - not against Git in general - and are not independently verified. The ~600 PB figure is a hypothetical estimate for naive fetching, not measured traffic. The viral "nearly 100× faster checkouts" is a rounding-up of Anthropic's actual phrasing, "minutes to seconds." And the separate "20× less memory, 4× faster" stat floating around belongs to a different ingestion-pipeline rewrite, not Scion. The practice is real and impressive; the funeral is editorial.

You Deleted the .env File From Git. Your Secrets Are Still Public.

Wed, 28 Oct 2026 08:06:21 +0000

You notice it during a code review: .env is in the repository. Your stomach drops. You run git rm .env, commit with the message "remove env file", push, and feel the relief of a problem solved.

It is not solved. The file is gone from your latest commit. It is sitting, in full, in every commit before that one, and anyone who can read the repository can read it.

Why Deleting Doesn't Delete

Git is a history book. A new commit adds a page saying "the file no longer exists". It does not tear out the old pages.

git log --all --full-history -- .env

If that prints any commits, your file is in history. And anyone can go back to it:

git show <old-commit>:.env

That works for a public repository on GitHub, for a coworker's clone, for a fork, and for any tool that scans old commits. Automated bots scan public repositories for exactly this, so a leaked key can be found quickly.

Step 1: Rotate Everything First

This is the part people skip, and it is the only part that actually matters.

Treat every secret that was ever in that file as compromised, and replace it:

Database passwords and connection strings
API keys (payment, email, storage, maps, AI)
Auth secrets such as NEXTAUTH_SECRET or JWT signing keys
OAuth client secrets
Webhook signing secrets

Create the new value, update your hosting environment, deploy, and then revoke the old one. Cleaning the history comes after, because cleaning cannot take back what someone already copied.

Rotating a signing secret logs users out, which is the right outcome. It means the old secret can no longer be used to forge sessions.

Step 2: Find Out What Else Was Committed

.env is not the only way secrets end up in Git. Search the whole history for the values themselves:

git log -p --all -S'sk_live' | head -100

-S finds commits where a string was added or removed. Try the prefixes of keys you use. A dedicated scanner is faster and more thorough:

gitleaks detect --source . --log-opts="--all"

It checks every commit for patterns that look like keys and tokens, and prints where it found them.

Step 3: Remove It From History

Once the secrets are rotated, you can clean the history so the old file stops being a trap. The current recommended tool is git filter-repo:

git filter-repo --path .env --invert-paths

This rewrites every commit as if .env had never been added. Because it changes commit IDs, you then force push:

git push --force --all

Be honest about the limits:

Everyone else must re-clone or reset, or they will push the old history back.
Forks and existing clones keep the old data. You cannot reach into them.
Hosting platforms may keep cached copies of old commits for a while. Check their guidance on removing sensitive data.

This is why step 1 comes first. History rewriting is cleanup, and rotation is the fix.

The Leak That Has Nothing to Do With Git

Next.js developers have a second way to leak a secret, and no commit is involved:

# .env.local
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_...

Any variable that starts with NEXT_PUBLIC_ is inlined into the JavaScript sent to the browser at build time. Anyone can open DevTools, read your bundle and find the value. The prefix means "this is safe to publish", and it does exactly that.

Rules that keep you safe:

Only values that are meant to be public get the NEXT_PUBLIC_ prefix, such as a public analytics ID or a publishable key.
Secret keys have no prefix and are read only in Server Components, Route Handlers and Server Actions.
If a secret ever got that prefix, assume it is exposed and rotate it.

Make It Hard to Repeat

Ignore the file before the first commit.

.env
.env.*
!.env.example

Commit a .env.example with the variable names and fake values, so teammates know what to set, and nothing real is ever in the repository.

Scan before commits leave your machine. A pre-commit hook with a scanner like gitleaks blocks a commit that contains something key-shaped. Hosting your code on GitHub also gives you secret scanning and push protection for many known key formats. Turn both on.

Fail loudly when a variable is missing. Check required variables at startup, so a missing secret becomes an error message, not a silent fallback to a hardcoded value that someone then commits.

The Rule

Once a secret has been in a commit, it is public forever. The fix is rotation, not deletion. Rotate first, clean the history second, and add a scanner so the next mistake is caught before it leaves your laptop.

Quick audit, right now, in your own project:

git log --all --full-history -- .env .env.local .env.production

If that prints anything, you have found a rotation task.

If you are starting a new Next.js project and want the structure set up sensibly from day one, you can browse my templates on pixelanas.com.

Get the templates: https://pixelanas.gumroad.com

Have you ever committed a secret by accident, and how fast did you notice? Tell me in the comments, and no judgment, this happens to nearly everyone once.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Oracle's Fusion Setup Registry Puts Configuration in a Public Git Repo for AI Agents

Mon, 26 Oct 2026 18:42:12 +0000

Setting up an enterprise application is slow work, and much of it gets repeated. Teams work out which settings depend on which, put the steps in the right order, test the result, and then do it all again for the next customer. The knowledge sits in documents that go stale with every release.

On Monday at Oracle AI World in Las Vegas, Oracle said it wants to move that knowledge into code. The company published the Oracle Fusion Setup and Configuration Registry, or FSCR, as a public Git repository. It holds Oracle's setup and configuration expertise as machine-readable skills that AI agents can run.

According to Oracle, the skills cover configuration options, dependencies, sequencing, execution, testing, and validation. An agent can take business requirements or an existing configuration and turn them into a runbook. It then makes the changes in Oracle Fusion Cloud Applications and tests the results. Human reviewers check the finished configuration, ask for adjustments, and approve it for deployment. Oracle says assistants and coding agents from OpenAI and others can use the registry.

Chris Leone, Oracle's executive vice president of Applications Development, said during the keynote that his team will own the registry. It will be updated with every release and with any patch that affects setup. He also said the skills warn you before you change an object that can't be reversed. "Agents will be the operator, and the registry will be the authority," he said.

Leone put it this way: "The Oracle Fusion Setup and Configuration Registry is like having an expert Oracle product manager guiding teams through the entire setup and configuration process." The release also carries supporting statements from Accenture Edge, Deloitte, PwC, Grant Thornton, and Apex IT. Each describes building its own accelerators on top of the registry.

The registry feeds Oracle AI Success Navigator, which now includes six agents: discovery, design, configuration, testing, integration, and innovation. Lexington Health, an early adopter, said the approach has cut certain design and configuration work by 80 percent during implementation. That is one customer's figure. Oracle didn't share a broader benchmark.

The keynote also showed what the agents do once they're running. Oracle calls its runtime Fusion Claw. It handles long-running, multi-step work such as reconciliation, analysis, and optimization, and Oracle says it supports continuous replanning and deterministic execution. Oracle says 25 Claw-powered agentic applications are available now across ERP, HCM, supply chain, and customer experience. Leone said Oracle is shipping 75 packaged agentic applications in total.

The live demo was a shipping load planner. The agent started with trucks at 61 percent utilization and proposed a plan to reach 88 percent, saving $58,000. It flagged five loads for a planner to review and cleared the other 149. After Leone approved, it rechecked the current state of the system before pulling in 117 orders and making the changes. Then it produced what he called an outcome receipt: who did the work, what actions were taken, and which standard operating procedures it followed. "AI with receipts," he said.

For developers, Oracle says customers and partners can build their own agents and agentic applications in Oracle AI Agent Studio for Fusion Applications, using no-code or pro-code tools. The release lists built-in observability, ROI measurement, and safety controls.

Oracle also announced Fusion Companion, which lets people work with Fusion through supported AI tools. It ships first as a plugin in OpenAI's marketplace for ChatGPT, with more AI clients planned. Companion decides whether a request becomes a transaction, an agent, an agentic application, or a long-running Claw job, and it applies the user's permissions. A second piece, Fusion Agentic Home, is a native mobile experience for Android and iOS that is voice-first.

The most useful material for builders came from the customers. QSRP, which Oracle says runs about 1,500 restaurants, built agents with Oracle for product availability, loss prevention, and delivery claims. In one demo, an agent grouped failed orders across stores and traced them to a single missing configuration in an Uber Eats integration. After approval, it fixed every affected store in one pass.

Sophie Buresi, QSRP's head of AI, said the pilot confirmed two things. "The hard part is not so much about AI. If you have the right data, AI is pretty simple," she said. The other is that operations teams have to trust a tool before they use it. To go from a few restaurants to hundreds, she said QSRP needs reliable data integration with its platform, results measured against the business case, and trust from the people running the restaurants.

Spectrum's approach was similar. Derek Dreyfus, the company's VP of HR technology and AI strategy, said his team treats governance as an accelerator. If an answer is repeatable and governed, an agent handles it. Anything involving a pay change, a process exception, or something sensitive in an employee's record goes to a person.

Oracle CEO Mike Sicilia built the whole keynote around trust. "Trust isn't something we can announce; it's something that we must earn," he said. For developers, trust shows up as things you can inspect: a receipt for every action, a threshold that sends exceptions to a human, and a registry in Git that you can read before you commit to it.

Oracle's materials leave some questions open. They don't cover licensing terms for the registry, how partner extensions will be vetted, or pricing for the Claw-powered applications. The best test is whether agents configure Fusion from the registry as cleanly as the demo suggested. Because the repository is public, teams can read the skills and check that for themselves.

GitHub Classroom has closed: what you still have, and how to run next term

Mon, 26 Oct 2026 16:09:06 +0000

Disclosure: I work on Uppcoder, one of the options listed at the end. The rest is about GitHub Classroom itself and applies whatever you choose.

GitHub retired GitHub Classroom on 28 August 2026. If your course ran on it, here is what is still there, what is gone, and what your choices are for the next term.

What happened, and when

GitHub closed new sign-ups to GitHub Classroom in May and retired it at the end of August. It now points educators to two partners: Classroom 50, free and open source from the Fifty Foundation, the nonprofit behind CS50, and Codio, a commercial platform.

26 May 2026: new sign-ups to GitHub Classroom closed
28 August 2026: GitHub Classroom retired; its website, APIs and related services decommissioned
GitHub's recommended partners: Classroom 50 and Codio

What you still have

GitHub says that GitHub accounts, repositories and organisations created to work with Classroom are not affected. Everything that lived in a repository is still where it was.

Your classroom organisation
Every student repository Classroom created, with its full commit history
Your template (starter) repositories
Any tests kept inside a repository, for example in a tests folder or a GitHub Actions workflow

What is gone, or going

GitHub says some Classroom data is being permanently deleted under its retention policies. GitHub's Classroom Export Utility downloaded this data as JSON and CSV files, but it worked through the Classroom APIs, which GitHub says are now decommissioned. If you ran it before 28 August, keep those files; if you did not, plan to rebuild what is listed here.

Classroom and assignment names
Tests defined in Classroom itself rather than in a repository (autograding set up on the Classroom website)
LMS-integrated rosters: the LTI link between Classroom and Moodle, Canvas and the rest

Finding your students' repositories

Classroom named each student repository after the assignment and the student's GitHub username, so the repositories of one assignment share a prefix. With the GitHub CLI (gh) you can list them, and clone them all into one folder. The roster that matched usernames to students was Classroom data; rebuild it from your LMS class list or your own records if you need it.

# list one assignment's repositories
gh repo list YOUR-ORG --limit 1000 --json name -q '.[].name' | grep '^assignment-prefix-'

# clone them all into the current folder
gh repo list YOUR-ORG --limit 1000 --json name -q '.[].name' | grep '^assignment-prefix-' \
  | xargs -I{} gh repo clone YOUR-ORG/{}

Before next term: a checklist

Whatever you use next, these steps keep last term's work safe and make the next one easier to set up.

Keep the organisation. Archive last term's student repositories rather than deleting them, if your school's retention rules allow it
Move tests into the template repositories, in a tests folder, so they travel with the assignment whatever tool you use next
Write down the assignment list with each template repository and its due dates, since the names in Classroom are being deleted
Check your LMS: if Classroom was linked to Moodle, Canvas, Blackboard or Brightspace, remove the old activity so students don't click into a dead end
Pick the replacement before the term starts and try one assignment end to end with a test student account

The options for next term

Each takes a different approach; which fits depends on your course, your school's rules on student data, and how much you want to run yourself.

Classroom 50 (free, open source, the Fifty Foundation): closest to GitHub Classroom, with assignments from template repositories, autograding through GitHub Actions, rosters and submissions, on GitHub. Needs an organisation on a GitHub Team or Enterprise plan (free for verified educators through GitHub Education) and a token with read and write access to the organisation's repositories
Codio (commercial, a GitHub partner): a hosted platform for coding courses with its own content, environments and autograding, and migration guides for GitHub Classroom users
Do it yourself with the GitHub CLI: for small courses, create the student repositories from a template with gh and a list of usernames, and mark by hand or with your own GitHub Actions; community tools shared in GitHub's own discussion of the change do this for you
Uppcoder (that's us; commercial, with a free tier): assignments are git repositories with starter code, tests and a solution; every student works in the same ready environment in the cloud, so nobody installs anything; tests mark each hand-in and you mark the rest by rubric; hand-ins can stay in your own GitHub organisation; it works inside Moodle, Canvas, Blackboard and Brightspace over LTI 1.3, or on its own;

If you choose Uppcoder: for teachers moving from GitHub Classroom we move one course across for you, up to ten of its assignments, and it runs free until 30 June 2027 (first 20 courses, one per teacher, up to 40 students, apply by 15 December 2026). Details: https://portal.uppcoder.com/github-classroom-alternative?utm_source=coderlegion&utm_medium=blog&utm_campaign=posts&utm_content=post-146

Sources

https://portal.uppcoder.com/github-classroom-closed?utm_source=coderlegion&utm_medium=blog&utm_campaign=posts&utm_content=post-146

What AI Coding Loses That Git History Can't Tell You — B Donald Harris

Mon, 26 Oct 2026 03:02:57 +0000

AI coding agents can generate code faster than ever—but can developers still explain why that code exists?

In this CoderLegion Developer Spotlight, software architect and founder B Donald Harris shares how AI-assisted development has reignited his passion for coding, why traditional Git history doesn't tell the whole story, and how he's building Hindsight to help developers understand the decisions, conversations, and reasoning behind their software.

From discovering programming on a Commodore 64 at age nine to exploring AI agentic workflows after more than two decades in software development, Donald offers a thoughtful perspective on the changing role of developers—and why the joy of building still matters.

Meet B Donald Harris

B Donald Harris is a software architect and founder based in Tulsa, Oklahoma. He has spent more than two decades building software, primarily in .NET and cloud technologies, and continues to explore new ways to build, learn, and collaborate.

His current work includes Hindsight, a workflow intelligence tool intended to help developers reconstruct how a software project evolved and understand why particular decisions were made.

Donald is also behind BIT Voices, a podcast and builder network created to showcase Black technology professionals, share their stories, and help builders discover and connect with one another.

Connect with Donald on CoderLegion:
https://coderlegion.com/user/BDonaldTechnologist

Why AI coding can leave developers with unanswered questions

AI coding agents can produce substantial amounts of code, help implement features, and accelerate development. But faster implementation creates another challenge: keeping track of everything that has changed and understanding the reasoning behind those changes.

As Donald explains in the interview, experienced developers might not remember every line of code they've written, but they can often recall the overall system design and know where to look when something goes wrong.

With agentic development, that understanding can become harder to maintain as changes and commits accumulate quickly.

A Git history may show that a feature was added, a bug was fixed, or an implementation changed. What it might not explain is why the team made that decision in the first place.

The missing context can live in conversations with AI agents, prompts, discussions between developers, terminal sessions, notes, and the reasoning behind architectural choices.

That is the problem Donald wants Hindsight to help solve.

Hindsight: Remembering the story behind software

Hindsight is a workflow intelligence tool Donald is building to help developers make sense of how their projects have evolved.

The concept is to connect a repository and bring together relevant development information, including:

Repository history, pull requests, and issues.
AI conversations and prompting sessions.
Terminal sessions and development notes.
Decisions made during implementation and debugging.
Changes in direction and the reasoning behind them.

By working with this information and a language model, developers could build a more complete account of their project's development journey.

Rather than relying exclusively on commit messages and code changes, the aim is to preserve the context that helps explain what happened, why it happened, and how the software reached its current state.

Donald describes the project as being in development and experimentation during the interview, with an MVP alpha targeted for the beginning of the following year.

He also emphasizes that privacy and control over what information is captured and seen are important considerations for builders using such a tool.

How AI has changed Donald's approach to development

One of the most interesting moments in the conversation comes when Donald reflects on how AI coding agents have affected his relationship with programming.

He started coding at nine after his father brought home a Commodore 64. Using a book of BASIC programs, he would type instructions and watch something happen on the computer. That experience felt like magic, and it sparked a lifelong interest in building software.

Over time, professional responsibilities and other commitments meant that coding sometimes became something he did primarily for work rather than for fun.

AI-assisted development has helped bring back that original excitement.

With agents taking on much of the implementation work, Donald can spend more time thinking about architecture, orchestrating agents, and bringing ideas to life—ideas he might not previously have had the time to explore.

His perspective is not that developers should abandon their skills or stop understanding their code. Instead, he sees AI as another step in the evolution of computing, much like earlier layers of abstraction that made software development possible.

The challenge now is learning how to work effectively with these tools while maintaining control over the systems being built.

From a .NET developer tool to AI agentic workflows

Donald also discusses a VS Code extension he created to simplify .NET project creation.

While exploring a move from Visual Studio to VS Code at work, he found that starting certain .NET projects required a sequence of command-line operations: creating solutions, creating projects, and adding projects to solutions.

He wanted a simpler workflow, so he explored the VS Code extension architecture and built a tool that automated those steps.

That project also became his first introduction to agentic workflows and helped shape his interest in how new tools could make development easier.

The experience reflects a recurring theme in Donald's work: identifying friction in the development process and finding practical ways to remove it.

Building BIT Voices and creating opportunities for others

Donald’s work extends beyond software tools.

Through the BIT Voices podcast, he provides a platform for Black technology professionals to share their experiences, work, and ideas. The accompanying BIT Voices Network is intended to help builders discover one another, showcase projects, connect, and potentially collaborate.

Donald explains that representation matters because technology professionals can be geographically and organizationally dispersed, sometimes with few opportunities to connect with others who share similar experiences.

He wants younger generations to see people like themselves building careers and creating opportunities in technology.

His decision to become more visible as a public builder is part of that mission: sharing his own work while helping others tell their stories.

Lessons from building products and communities

The interview touches on several lessons that extend beyond AI tooling.

1. Don't lose the joy of building.

Donald says the advice he wishes he had received earlier in his career was to never stop doing software development for fun. Personal projects can provide room to experiment and rediscover the excitement that first drew someone to programming.

2. Understand the reasoning, not just the implementation.

Code and commits tell part of a software project's story. The discussions, decisions, and context behind them can be equally important when maintaining or extending a system.

3. Learn to embrace technological change.

Donald sees AI as another stage in computing's evolution. Rather than dismissing it, developers can learn how to use it effectively while continuing to apply their own judgment.

4. Pay attention to how the software actually works.

Building and testing a product can reveal workflows that differ from the assumptions made during initial design. Donald emphasizes learning from those discoveries rather than rigidly following preconceived ideas.

5. Start building.

His advice to developers who want to create their own products is straightforward: start. Developers already have many of the skills needed to outline a project and begin turning an idea into something real.

Watch the full conversation

In this CoderLegion Developer Spotlight, Donald and host Tom Smith explore AI-assisted development, software architecture, Hindsight, the importance of developer context, and the work involved in building products and communities.

The conversation is particularly relevant for developers experimenting with AI coding agents and thinking about how to maintain a deeper understanding of increasingly complex codebases.

About the interviewer: Tom Smith

Tom Smith hosts this CoderLegion Developer Spotlight, speaking with developers and builders about their experiences, technical decisions, projects, and lessons learned along the way.

Connect with Tom on CoderLegion:
https://coderlegion.com/user/Tom Smith

About CoderLegion Dev Stories

CoderLegion Dev Stories shares the experiences behind software development: the people building products, the problems they solve, the decisions they make, and the lessons they learn.

If you're building something interesting, exploring a new technology, or learning from real-world development challenges, consider sharing your story with the CoderLegion community.

Explore CoderLegion: https://coderlegion.com

Keep building, keep sharing, and keep learning from one another.

surviving-lines scored highest in a six-arm code-ownership benchmark

Sat, 24 Oct 2026 11:15:17 +0000

I wrote surviving-lines to answer one question: who wrote the code that is still in this repository? It is a command-line tool that counts each author's surviving lines with git blame and prints them next to the author's share of commits. It also ships as a Claude Code plugin, so an agent can run it instead of estimating. For version 0.4.0 I wanted to know whether the plugin changes how well an agent answers ownership questions. So I measured it against three other tools and against Claude with no plugin.

The short result: on 5 sealed tasks the plugin scored 9.67 of 25 and the best other arm scored 7.33. The 95% bootstrap interval of that difference is [+0.33, +4.33], so it stays above zero but only just. A score of 9.67 of 25 also means that the plugin passed fewer than 4 criteria in 10, so these tasks are hard for every arm. On 11 public tasks, which I had read while developing the tool, it scored 47.67 of 51 against 41.00 for the best other arm. It did not win every task, and the details are below.

What was measured

Each task gives an agent a git repository and a question that a person taking over a project would ask, for example "Who should I ask to review changes to time.go, version7.go and the SQL code, and are the people who actually wrote those parts still around?" A task has five criteria or fewer, such as "names this person as the top owner with a share between 51% and 59%" or "does not credit the person who only ran the formatter". The criteria were written with a ground truth computed from the repository, and a model grader scored each answer against them. The grader gave its reason before its verdict, with five votes per criterion, and the verdict is the majority.

There are two sets of tasks:

The sealed set has 5 tasks. An agent that had not seen the surviving-lines repository wrote them. It was given a plain description of the user's job and the file layout. Each task uses a real open-source repository in a different ecosystem (Python, Go, Zig, Ruby, PHP) with commits added by the writer that create hazards: a formatter run, the same person under several addresses, squash-merged work, mechanical file moves, an author who differs from the committer.
The public set has 11 tasks. It uses one small JavaScript repository where the main author has two addresses, asked in several ways (who owns the code, the bus factor of a directory, who should review a file, code owners per directory and so on). The tasks were read while the tool was being developed, so I label the set development-seen. The claim in this article rests on the sealed set.

The six arms are surviving-lines at commit 8af57f4, project-pilot 1.0.0 with its natural prompt and again with the prompt "Use the /project-pilot:bus-factor command for this.", mcp-git-historian, busfactor by k41n, and a Claude Code run with an empty plugin. The other tools were run from copies pinned at the commits listed in the evidence folder. project-pilot 1.0.0, invoked only has runs on the 8 public tasks that define an invoked prompt, so its public total counts the other 3 tasks as 0. Each arm ran each task three times on Sonnet 5.5 through Claude Code 2.1.308. The protocol was committed before the first run, and no result from an earlier round was reused. Version 0.4.0 on npm ships the same plugin code as that commit: the bin, hooks, agents and schema folders are byte-identical, and only the skill description text and version number differ.

Sealed set

arm	total of 25
surviving-lines	9.67
project-pilot 1.0.0, invoked	7.33
no code-ownership plugin	3.33
busfactor (k41n)	2.67
project-pilot 1.0.0	2.33
mcp-git-historian	2.00

A total is the sum over the tasks of the mean criteria passed over the three runs. The difference to the best other arm, project-pilot 1.0.0, invoked, is +2.33 with a 95% interval of [+0.33, +4.33]. Against the other four arms the differences are between +6.33 and +7.67, and every interval is above zero. With 5 tasks and 3 runs, the lower bound of 0.33 is close to zero, and a different set of tasks could move it either way.

The protocol also defines stricter checks, and the plugin fails them on this set. On HZ3 it scored 0.67 where project-pilot 1.0.0, invoked scored 1.33, and on HZ5 it scored 1.33 where the empty-plugin run scored 1.67. The per-task rule (rule B), under which the plugin may not trail the best rival on any task, therefore fails, and so does the rule that the plugin must lose at most 80% of the points the best rival loses: it lost 15.33 of 25 and the rival lost 17.67, where the limit was 14.13. I do not claim it is first on every task.

Public set

On the public set the plugin scored 47.67 of 51. The best other arm was the empty-plugin run at 41.00, and the difference is +6.67 with an interval of [+5.00, +8.33]. Against project-pilot taking the better of its two arms on each task, the difference is +4.33 with an interval of [+2.00, +6.00]. The totals of the other arms are 40.33 (project-pilot 1.0.0), 40.33 (busfactor), 38.33 (mcp-git-historian) and 27.33 (project-pilot 1.0.0, invoked, with the 3 missing tasks).

It lost three tasks: T1 and T1i, where it scored 3.00 and busfactor and the empty-plugin run scored 4.00, and E5, where it scored 4.00 and mcp-git-historian scored 5.00. The 80% rule passes on this set. The per-task rule fails on those three tasks. Because these tasks were read during development, a high score here is weaker evidence than the sealed result.

Other models

I ran Haiku 5.5 and Opus 5.5 once per task, with only surviving-lines, the empty-plugin run and the best rival of each task. These totals are descriptive. One run per task is too few to compute an interval, and I make no claim of being first from them.

model	set	surviving-lines	empty plugin	best rivals, summed per task
Haiku 5.5	sealed, of 25	6	3	0
Haiku 5.5	public, of 51	46	33	33
Opus 5.5	sealed, of 25	15	12	14
Opus 5.5	public, of 51	51	39	43

The plugin is ahead in total in all four rows. The per-task rule fails on several tasks for both models, except on Opus with the public set.

How much to trust the grading

I regraded a random sample of 28 of the 279 graded cells with fresh grader sessions. The new grade agreed with the first on 129 of 131 criteria (98.5%), and no cell moved by more than one point. I also ran the same 28 cells again once. 25 of those 28 re-runs scored within the range of the three original runs, so a single run of a cell can differ from the earlier ones. On the sealed set the five votes were unanimous on 91.6% of verdicts and on the public set on 97.0%.

What it costs and what went wrong

At list price the plugin costs 1.67 times the empty-plugin run per cell on the sealed set (0.117 US dollars against 0.070) and 1.56 times on the public set (0.076 against 0.049), because it uses more turns and tokens. The runs were charged to a subscription. The whole round, including the development gates that decided whether to run the final measurement, would cost 185.46 US dollars at list price.

The plugin has a Stop hook that checks the numbers in an answer once before the agent finishes. It blocked the first answer in 5 of 48 plugin cells (10.4%). Those cells scored 3.40 on average and the unblocked ones 3.60 criteria, so this data does not show whether the hook helps.

These points limit the result:

The tasks are ours. The sealed writer did not read the surviving-lines repository, but the agent that ran the measurement saw the writer's closing summary (the five repositories and a line of hazards per task) before I wrote the protocol. The hazards are the ones the tool was built to handle. A benchmark by someone who builds a rival could rank the arms differently.
Five sealed tasks is a small set, and the intervals reflect only the three runs per task, not a different choice of tasks.
One model produced the sealed and public runs, one CLI version, one login.
The session limit stopped the drivers twice, both times during the audit re-runs. Cells that failed on a limit were set aside, never graded, and run again, and no scored run was set aside. I renewed the login after the second stop, so the audit re-runs after that point and the other-model runs may have gone through a different account.
The sealed scripts are published with contributor addresses replaced by their SHA-256. The published scripts rebuild the fixtures with the same commit ids and reproduce the ground truth byte for byte.
The interval of each arm's own total in the figure is not printed in the evidence summary, which only has intervals of differences. I computed them from the same grades with the same method (intervals.py, next to the figure script), and it checks its totals against the summary.

The benchmark above asks whether an agent uses the tool well. A separate question is why the tool counts both numbers. In September I ran it on twelve public repositories, with the design and the meaning of a null result written down first. For each repository I measured every author's share of non-merge commits and share of surviving lines at HEAD, from a one-in-five deterministic file sample, with three seeds per repository. That is 36 runs and 2,748 author rows, measured on 5 September 2026 with version 0.1.6.

The author with the most commits also held the most surviving lines in 25 of the 36 runs, and on all three seeds in 8 of the 12 repositories. Commit counts therefore usually point at the right person. The gap between the two shares is larger than that suggests: among authors holding at least 5% of either measure (122 author rows), the median gap was 7.5 percentage points and the mean 12.2. 43 of the 122 (35%) differed by 10 points or more, and the largest single gap was 63.8 points. In cloudflare/capnweb the top committer, holding 46% of commits, held between 3% and 16% of the sampled surviving lines depending on the seed, while a contributor with 2% of the commits held 45% to 58%. I did not look into why.

This has limits. Twelve repositories describe twelve repositories and are not a statement about open source. The sample moves the magnitudes: the top author's line share had a median spread of 5.4 points across seeds and a maximum of 17.4, so I read a direction from one run and a magnitude from several. The tool counted bots as authors in that run, and since 0.3.0 it leaves them out by default, so that table has not been re-run with the current behaviour. Surviving code is not merit, since code can stay because nobody dares to touch it. HEAD has moved on in all twelve repositories and the data file records no commit ids, so a re-run will give different numbers.

Try it and check it

npx surviving-lines --sort gap

--sort gap puts the author with the largest difference between line share and commit share first. The tool needs Node 22 or newer and git 2.15 or newer. To use it from Claude Code:

/plugin install surviving-lines --marketplace Bubblegunn/surviving-lines

Every cell, the departures from the protocol and a recompute step are in the round 13 evidence folder. REPRODUCE.md in that folder gives the commands for a re-run, and the earlier rounds and rulings are in docs/HEAD-TO-HEAD.md. The repository is Bubblegunn/surviving-lines, and version 0.4.0 is on npm. I wrote about the first version of the tool in September: Who really owns this code? A git blame sampler you can run in one command.

Three people outside my own commits have shipped code in the tool: @shivam-070208 wrote --markdown, @Aaqibhafeezkhan wrote --sort gap, and @Enard52 sent fixes that make empty runs say which filter emptied them. If you run it on something and the numbers look wrong to you, tell me which repository and I will look.

Disclosure: I drafted this article with AI assistance (Claude) and reviewed it myself. Every number comes from the evidence folder linked above and the research folder in the repository, and the benchmark can be re-run from it.

You Ran git reset --hard and Panicked. Here's How to Get Your Commits Back (and the One Thing You Ca

Fri, 23 Oct 2026 10:54:58 +0000

Your stomach drops. You typed git reset --hard, or deleted the wrong branch, or a rebase ended with half your commits missing. The log looks empty. Three days of work, gone.

Take a breath. If you ever committed that work, it is almost certainly still there. Git is much harder to destroy than it looks, and the tool that proves it is called the reflog.

What the Reflog Is

Your normal history (git log) shows the commits reachable from your current branch. The reflog is a different record: a private diary of everywhere HEAD has pointed on your machine, in order, including places you have since left.

git reflog

a1b2c3d HEAD@{0}: reset: moving to HEAD~3
9f8e7d6 HEAD@{1}: commit: add pricing page
4c5d6e7 HEAD@{2}: commit: fix navbar on mobile
b7a8c9d HEAD@{3}: commit: add contact form

A hard reset moved your branch pointer backwards. It did not delete the three commits. They are still stored, and the reflog tells you their IDs.

Disaster 1: `git reset --hard` Threw Away Commits

Find the entry from just before the mistake and go back to it:

git reflog
git reset --hard 9f8e7d6

You can also use the position instead of the ID:

git reset --hard HEAD@{1}

Your branch is back exactly where it was. The "lost" commits are the same commits, same IDs, nothing rewritten.

Disaster 2: You Deleted a Branch You Still Needed

git branch -D feature/checkout
# Deleted branch feature/checkout (was 3e4f5a6).

Look at that output. Git told you the ID of the commit the branch pointed at. If you missed it, the reflog still has it:

git reflog
# find the last commit you made on that branch
git checkout -b feature/checkout 3e4f5a6

A branch is only a label that points at a commit. Delete the label and the commits stay, until Git cleans them up much later.

Disaster 3: A Rebase Went Wrong

Mid-rebase mistakes feel the scariest, because rebase rewrites history. It still keeps the old version in the reflog.

Right after a rebase, ORIG_HEAD points at where you were before it started:

git reset --hard ORIG_HEAD

If you have done other things since, find the entry that says something like rebase (start) in the reflog, take the entry just before it, and reset to that.

Disaster 4: You Dropped a Stash

git stash drop removes the stash from the list, but the commit it was stored in still exists for a while. If you have the ID that was printed, apply it directly:

git stash apply 7a8b9c0

If you do not have the ID, search for unreachable commits:

git fsck --no-reflog | grep "dangling commit"

Then inspect each ID with git show <id> until you find your changes. This is slower and less certain than the reflog, so treat it as the last resort.

The One Thing You Cannot Recover

This is the part many tutorials skip.

Changes you never committed and never staged are not in the reflog, and git reset --hard deletes them permanently.

The reflog records commits. If you edited files, never ran git add or git commit, and then ran git reset --hard or git checkout . or git restore ., those edits are not stored anywhere in Git. There is nothing to recover.

A small mercy: if you did run git add, the staged file contents were saved as objects, and git fsck --lost-found may be able to find them. It is messy, but possible. Unstaged edits have no such safety net.

Why Reflog Entries Do Not Last Forever

The reflog is local to your machine, and it expires. By default, entries for commits that are still reachable are kept for about 90 days, and entries for unreachable ones for about 30 days. After that, Git's cleanup can remove the commits for good.

It also lives only in your clone. A fresh git clone has an empty reflog, and it cannot help you recover something that was lost in someone else's copy.

How to Make This Less Scary Next Time

Commit early, even when it is messy. A commit called "wip" is a safety net. You can clean the history up later with an interactive rebase.
Stash before you experiment. git stash takes a snapshot you can come back to.
Use --force-with-lease instead of --force. It refuses to overwrite a branch if someone else pushed commits you have not seen yet.
Read what Git prints. Deleting a branch tells you the ID. Copy it somewhere before doing anything else.
Create a rescue branch first. Before any risky command, run git branch backup-before-rebase. It costs nothing and gives you a label to return to.

The Rule

If you committed it, Git almost certainly still has it. Open git reflog before you do anything else. And if you are about to run a command that can discard work you have not committed, commit or stash first.

Quick drill: make a throwaway repo, create three commits, run git reset --hard HEAD~3, and get them back with the reflog. Do it once when nothing is at stake, and the real thing is not scary any more.

If you build with Next.js, my templates on pixelanas.com give you a clean starting point, which is a good first commit to have in your history.

Get the templates: https://pixelanas.gumroad.com

What is the worst thing you have ever lost to a Git command, and did you get it back? Tell me in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Why Git Blob IDs Mismatch Your File Checksums

Mon, 19 Oct 2026 02:25:56 +0000

Comparing a raw file digest with a Git object identifier often reveals unexpected mismatches. Developers frequently notice that running a standard local hashing tool on a file produces a different checksum than the one returned by Git or the GitHub Git blobs REST API. This discrepancy occurs because Git does not hash raw file bytes directly. Instead, Git constructs an object header that includes the object type and byte length, prepends it to the content, and hashes the combined payload.

Quick solution:
To calculate the exact Git blob object ID locally, prepend the object type and byte length header followed by a null byte before hashing the raw content.

printf "blob %d\0%s" "$(wc -c < file.txt)" "$(cat file.txt)" | shasum

Prerequisites include a standard Unix shell environment with shasum or sha1sum, and wc for counting exact byte lengths. Be aware that trailing newlines or varying shell implementations of printf can alter the generated byte stream.

Why Does Hashing Raw File Bytes Produce Another Value?

When you run a command like openssl dgst -sha1 file.txt or shasum file.txt, the utility reads the raw byte sequence of the file and feeds it directly into the cryptographic hash function. This yields a pure content digest. Git, however, treats files as version-controlled objects rather than flat storage blocks. According to the Git hash-object documentation, every stored object receives a header composed of its type (such as blob), a space, the size of the file in bytes, and a null byte (\u0000) acting as a separator.

For example, if a file contains the exact text hello, its byte length is 5. Git constructs the internal byte sequence by joining the string blob 5, a null byte, and the five characters of content. Hashing this combined stream produces the unique Git object identifier. Because the raw file digest lacks the header, metadata, and null separator, the resulting checksum diverges completely from the Git blob ID. Developers optimizing performance workflows often review prior indexing patterns, such as those detailed in our guide on Google Search Console Content Prioritization, to ensure metadata indices align properly with storage identifiers.

How Is UTF-8 Byte Length Different from String Length?

Calculating correct object identifiers requires precise byte counting rather than character or string length measurements. In ASCII text, one character equals one byte. However, modern codebases frequently utilize multi-byte UTF-8 characters, emojis, or specialized symbols.

Consider a text file containing a single multi-byte character, such as the euro symbol (€). In UTF-8 encoding, this character occupies three bytes. If an application measures string length by counting logical characters, it might report a length of 1. If Git then calculates the header using that incorrect length, the resulting object hash will fail to match the repository database or API response. Engineers must always measure exact byte counts using tools like wc -c or native byte-length methods in programming languages rather than relying on character-length functions.

When Must Application Integrity Use a Separate Digest?

Relying on Git object IDs for external application security or file verification introduces architectural risks. Because Git object identifiers depend on the internal repository header and the chosen hashing algorithm (such as SHA-1 or newer experimental formats like SHA-256), they are tightly coupled to version control internals rather than raw file content.

Option	When to Use It	Trade-off or Failure Mode	Recommendation
Git Blob ID	Verifying repository object storage and API blob parity	Tied to Git metadata headers and vulnerable to SHA-1 collision concerns	Use strictly for Git repository tooling and GitHub REST API integration
Raw File Digest	Verifying independent file downloads, caches, or releases	Ignores repository metadata and commit context	Use standard SHA-256 or BLAKE2 for general application integrity checks

Applications that require independent file verification, artifact signing, or secure distribution must rely on a dedicated raw digest computed directly from the file bytes. Treating Git object IDs as universal file checksums creates fragile verification pipelines that break when files are checked out with different line ending configurations, such as CRLF versus LF normalization.

Additional Scenarios and Failure Modes

In addition to the differences between raw file digests and Git blob IDs, there are other scenarios where the two may diverge. For instance, when a file is modified, the Git blob ID will change, but the raw file digest may not if the modification does not affect the file's content. Similarly, if a file is renamed or moved, the Git blob ID will remain the same, but the raw file digest may change if the file's content is modified during the rename or move operation.

Execution and Verification Checklist

[ ] Verify empty content matches git hash-object by running an empty file through the header generation command and comparing it against git hash-object --stdin. Expected result: hashes match the known empty blob identifier e69de29bb2d1d6434b8b29ae775ad8c2e48c5391.
[ ] Test non-ASCII text using exact byte length calculations rather than character counts to ensure multi-byte symbols generate matching object IDs.
[ ] Confirm a one-byte modification alters both the raw digest and the Git blob identifier, validating that minor edits propagate correctly through the header generation step.
[ ] Document environment specifics, shell versions, and encoding parameters before deploying any automated script that compares raw file checksums against Git repository objects.
[ ] Verify the behavior of Git blob IDs and raw file digests in different encoding scenarios, such as UTF-8, UTF-16, and UTF-32.
[ ] Test the performance impact of using Git blob IDs versus raw file digests for large files and repositories.

Conclusion

In conclusion, the discrepancy between raw file digests and Git blob IDs arises from the inclusion of a header in the Git object identifier. This header contains the object type, byte length, and a null separator, which are not present in the raw file digest. Understanding the differences between these two types of identifiers is crucial for ensuring data integrity and security in version control systems and application development. By using the correct type of identifier for the specific use case, developers can avoid potential pitfalls and ensure the reliability of their workflows.

Alternatives to the DevLabs Pull Request Merge Conflict Extension (2026)

Wed, 14 Oct 2026 13:44:34 +0000

title: "Alternatives to the DevLabs Pull Request Merge Conflict Extension (2026)"
published: true
description: "Microsoft's DevLabs merge conflict extension for Azure DevOps is no longer maintained. An honest comparison of the alternatives: resolving locally, your IDE, and a maintained extension."
tags: azuredevops, git, devops, productivity
canonical_url: https://jr-devtools.com/guides/devlabs-merge-conflict-extension-alternatives/

cover_image: https://jr-devtools.com/merge-conflict-resolver/screenshot-editor.png

Originally published on jr-devtools.com.

For years, the free Pull Request Merge Conflict Extension from Microsoft DevLabs (ms-devlabs.conflicts-tab) was how teams resolved conflicts without leaving Azure DevOps. It is no longer maintained. Here's what's going on and what you can use instead.

Disclosure: we make Merge Conflict Resolver, one of the options below. We've tried to keep this comparison fair; corrections are welcome at support@jr-devtools.com. Last checked: October 2026.

Is the DevLabs extension still supported?

No. Its last update was in November 2023, and Microsoft wrote in the extension's Q&A that “there are no current development resources for this extension”. Questions like “Is this even supported anymore?” go unanswered. Since 2024 its reviews average about 1.6 out of 5. The most reported problems:

the tab freezes or keeps “taking longer than expected to load”, and work is lost when it crashes;
non-ASCII characters (ä, é, č, Hebrew, Chinese …) are changed, especially in UTF-8 and ANSI files;
you can only take a whole file from one side, not choose per conflict or keep both;
the resolution lives only in the pull request's merge commit, so reviewers and builds never see it;
large files such as package-lock.json, or many conflicts, make it hang.

It still works for some teams on simple conflicts, so there's no need to remove it in a hurry. But if you run into the problems above, there won't be a fix.

The alternatives

1. Resolve locally with Git (free)

Merge the target branch into your source branch, resolve in your editor, and push. See our step-by-step guide.

Good: free, always works, you can build and test before pushing. Less good: you need the repository cloned and a working Git setup; slow for a two-line fix or for someone else's pull request.

2. Your IDE's Git integration (free)

Visual Studio, VS Code and JetBrains IDEs all have 3-way merge editors. In Visual Studio, check out the source branch, merge the target branch from Git → Manage Branches, and resolve in the merge editor.

Good: comfortable editor with IntelliSense. Less good: same as locally: you need a clone, and it's per developer, not something a reviewer can do from the pull request.

3. Merge Conflict Resolver (free plan, Pro from $12 per organization per month)

Merge Conflict Resolver is an independent, actively maintained extension that adds a Resolve conflicts tab to pull requests, built to fix the problems above:

3-way editor (Monaco, the editor of VS Code) with Accept target / source / both per conflict;
drafts are saved in the browser, so a reload or crash never loses work;
UTF-8, UTF-8 with BOM, UTF-16 and Windows-1252 files and their line endings are written back byte for byte;
edit/delete, renames, binary files, Git LFS and submodules each get a clear choice;
stays responsive with hundreds of conflicts and multi-megabyte lockfiles;
Pro: commit the resolution to the source branch, a summary comment on the pull request, bulk and whitespace auto-resolve.

Good: no clone needed, anyone on the pull request can resolve. Less good: Azure DevOps Services only for now (not Azure DevOps Server); Pro is paid. The free plan covers 10 pull requests per organization per month, and every organization gets a 14-day Pro trial.

Side by side

DevLabs extension	Locally / IDE	Merge Conflict Resolver

Switching from the DevLabs extension

Both extensions can be installed side by side, so you can try before you remove anything. An organization admin installs Merge Conflict Resolver from the Visual Studio Marketplace; there's nothing to configure, and the 14-day Pro trial starts the first time someone opens the tab.

Not affiliated with Microsoft. “Azure DevOps”, “Excel” and “Office” are trademarks of Microsoft.

Use Git Sparse-Checkout to Scope Agent Worktrees

Wed, 14 Oct 2026 12:16:17 +0000

A coding agent assigned to one package may not need every sibling directory in a large repository working tree. Git worktrees provide separate working directories associated with one repository, while sparse-checkout limits which tracked paths are populated in a particular working tree.

Quick solution:

git worktree add -b agent/payments ../agent-payments main
cd ../agent-payments
git sparse-checkout init --cone
git sparse-checkout set packages/payments packages/shared
git sparse-checkout list
git status --short

Setting Up Scoped Worktrees

When managing large monorepos, populating every single directory for every agent task consumes unnecessary disk space and adds noise to the agent context. You can isolate tasks by combining worktrees with path restrictions. Start with a dedicated branch and worktree, then configure the specific paths the task needs.

In cone mode, account for root-level files and the selected directories when reviewing what appears in the working tree. Add only the build, test, and shared files the task requires. The official Git sparse-checkout documentation describes pattern behavior and cone mode operations. Additionally, the Git worktree documentation explains linked working directories and shared repository data, while the GitHub sparse-checkout guide provides broader monorepo context.

Keeping Visibility Separate from Enforcement

Sparse-checkout is a workspace convenience, not a security boundary. An agent or tool with repository access can change sparse patterns or use Git commands to inspect other tracked content. If a task must not modify unrelated paths, enforce a separate allowlist in the integration system and reject any diff that changes paths outside the task approved set. Protect credentials and sensitive files with actual access controls or sandboxing rather than relying on workspace population rules.

A diff allowlist can catch an out-of-scope change before integration. It does not prevent the agent from reading or attempting to edit that file earlier, so treat it as a merge gate rather than a permission system.

Verification Checklist

Confirm the worktree uses the intended branch and base commit.
List the sparse paths and inspect which root files remain present.
Run the required build and tests in that worktree.
Compare the final diff to a separately enforced path allowlist.
Record measured file or context changes only when the measurement method is reproducible.

Managing Agent Worktrees in Git

Sat, 10 Oct 2026 00:03:48 +0000

Running parallel AI coding agents across shared repositories via Git worktrees prevents duplicate cloning, but it exposes critical operational edge cases. When multiple automated workers operate simultaneously within the same repository infrastructure, subtle concurrency conflicts can compromise shared history. Managing safe cleanup and ephemeral lifecycles for these parallel AI coding agents without corrupting shared Git refs or reflogs requires strict boundaries between working tree modifications and global repository state. For a related implementation, see Shared Git State In Parallel Agent.

The Silent Hazard of Shared Git State

Git worktrees share the underlying object database and repository reflogs, even though they maintain separate working directories. When an agent runs a destructive command like git reset --hard or git branch -D, it silently mutates history that every sibling worktree and human developer observes. This creates insidious, invisible state drift that only surfaces during high-pressure rollbacks or post-mortems.

Furthermore, when multiple agents spawn simultaneously and attempt to claim branch names dynamically at runtime, they crash because Git strictly refuses to check out the same branch in more than one worktree at a time. Agents frequently produce broken code, failed test runs, or malformed diffs that require discarding, but giving an autonomous agent access to global reset commands gives it the power to destroy commit pointers across the entire shared repository.

The Command Boundary

To prevent reflog contamination, agents must be strictly prohibited from executing ref-mutating commands. Instead, agent tool definitions only permit scoped working tree operations that isolate changes to the local filesystem boundary. Whitelisting specific recovery commands protects the underlying repository while still giving workers the ability to clear their scratchpads.

git restore .
git clean -fd

Running git restore . reverts modified tracked files back to the current HEAD of that worktree without touching commit history or reflogs. Meanwhile, git clean -fd purges untracked build artifacts and scratchpad directories. This guarantees that local mistakes cannot leak beyond the worktree boundary or pollute the shared audit trail.

The Cattle Pattern for Agent Worktrees

When an agent encounters a catastrophic error requiring a full structural rollback across multiple commits, the agent does not attempt in-place recovery. The central orchestrator treats the worktree as disposable cattle rather than a persistent environment.

When a failure occurs, the orchestrator terminates the agent, forcefully deletes the worktree, prunes worktree metadata, and provisions a fresh worktree from a verified canonical commit.

# Orchestrator-managed cleanup from outside the worktree
git worktree remove --force agent-task-742
git worktree prune

This external destruction pattern isolates failures completely. By executing these commands from the parent control plane, the system avoids leaving dangling locks or corrupted references in the .git/worktrees/ directory.

Deterministic Scheduling

To completely eliminate branch checkout races, branch naming must be removed from the agent's responsibility entirely. If agents generate branch names at runtime, simultaneous requests inevitably collide.

The orchestrator should instead generate deterministic, collision-free branch names before any worktree is created. By assigning namespaces using a predictable format such as agent/<task-id>/<timestamp>, the system ensures zero runtime conflicts during parallel initialization. For a related implementation, see Audit Macos System Data Before Deleting.

Conclusion

Safely scaling parallel AI coding agents inside Git worktrees requires shifting away from manual developer habits. By separating scoped working tree cleanup from global reference mutations, treating broken worktrees as disposable cattle, and pre-allocating branch namespaces centrally, engineering teams can maintain clean reflogs and reliable auditability without sacrificing execution speed.

My First Project: From a Local Folder to GitHub Using Git and SSH

Thu, 08 Oct 2026 04:21:17 +0000

My First Project: From a Local Folder to Git hub Using Git and SSH

GIT

Introduction

Git is an open source version control system used to manage projects. It is fast and efficient to manage projects using git. You can easily track the project version, history, modifications, and many more project activities. It allows for ease of collaboration while working on projects as teams.

Installing Git

Download and install git from Git. Ensure you download for your respective operating system.

Configuring Git

Before using Git effectively, you have to configure your identity by setting up your username and email.

This allows to easily track any changes to your project and the associate, that is; who made the changes?

To set up your identity, follow the following steps, using Git Bash a git terminal:

Steps

To set your username

git config --global user.name "YOUR NAME"

In place of YOUR NAME type in your correct user name that will be associated with your github account activity.

To set your email

git config --global user.email "youemail@example.com"

Note: It is recommended to use your correct email that is associated with your GitHub account.

Rename you GitHub branch to main

git config --global init.Branch main

After setting up your identity you can verify your configurations to confirm your identity for each field set.

To check your:

User name

`git config --global user.name`

`git config --global user.email`

Branch

git config --global init.Branch`

You can use the following command to check all you account details instead:

`git config --global --lists`

SSH

SSH key is a secure credential used to authentication to accessing network resources confidentially without need of a password. The ssh-key contains two keys. A Public and Private key.

Public key is used publicly, that is it is shared between peers. Used to identify you remote resources.

Private key it is a pair key that is kept as a secret for identifying your local machine.

Generating an SSH Key

Using Git Bash

Before generating a new SSH Key, it is recommended to check and confirm if you have an existing key which you can use.

To check if you have an existing key use the following command:

`ls -al ~/.ssh`

The command will list all existing ssh keys. Here sample output:

If there is no existing key, you can generate a new key that you will use to link your computer with your github account.

To generate a new ssh key, follow the following steps:

Genereate a new ssh-key

ssh-keygen -t ed25529 -C "youremail@example.com"

The email should be the one associated with with your github account.

Follow the prompt by adding the name of your key, and also you can add the passphrase which is optional.

The passhrase should be memorable, you will need to use it each time you want to access you github account.

Add your key to the SSH-Agent.

Open your Powershell Terminal and follow the steps below:

- Run the following command to start your SSH Agent

	`Get-Service -Name ssh-agent | Set-Service StartupType Manual`

- Add your key to the  path using the  command

	`ssh-add <PATH/TO/YOUR/PRIVATE_KEY>`

After the command, you should specifify the path to your private key and add it to your host machine's ssh-agent. i.e. ssh-add "C:/Users/<YOUR_USER_NAME/.ssh/<YOUR_PRIVATE_KEY>

If you don't know your computer's user name, you can use the whoami command to see your username.

Your _PRIVATE_KEYNAME is the name that you gave to your key.

- Once you're done, close your Powershell terminal and return to Git Bash.

- Type the following command

	`git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe`

- Then Clip and copy your key using the following commands:

	`clip < ~/.ssh/<PUBLIC_KEY.pub>`

i.e clip < /.ssh/my_key.pub

	`cat ~/.ssh/<PUBLIC_KEY.pub>`

i.e. 'cat ~/.ssh/my_key.pub` to view your public ssh key

- After displaying your key, select and copy the key to add to your GitHub account.

Adding Your Key to GitHub

To connect your computer and git-hub is necessary to facilitate access to your remote resources from your local computer.

You need to add your SSH Keys to GitHub to facilitate the connection. To achieve this, follow the steps:

If you have an existing GitHub account:

a. Login to your account using your email/username and password.

b. From the profile section, go to Settings

c. Scroll to SSH and GPG Key. Navigate and click on New SSH Key on the SSH Key Section to your right.

e. Add the Title/Name of the key i.e. Ubuntu Laptop, the key will be used for Authentication

f. Paste your key to the available textbox.

g. Finally, click on Add Key to save your key. You'll be prompted to re-enter your git-hub account password (login password), to confirm your authenticity before saving.

Now you are ready to go. Before you start, it is good you test your connection to check if it was successful.

Run Powershell as an Administrator and use the following command to test connection:

`ssh -T git@github.com`

If the connection is successful, your username will be displayed along with a success message.

If successful, you are good to go and work on your project.

Working With Folders

To keep you project structural and more organized; you've to keep its files and scripts in folders.

This will make it easier to navigate and access the project. Follow the steps below to work with folders in Windows.

In Git Bash Terminal(Opened normally)

To navigate and change location use the following command
```
`cd <path_location>`
```

To select the current location

	`cd .`

To get to the previous location one step back use

	`cd ..`

Getting back to the root directory use

	`cd ~`

You can also move to a specific folder by specifying the path to that folder

	`cd <path/to/folder>

example: cd "C:/Users/Admin/Desktop/My-Project"

My-Project/ is a folder located in Desktop, which is for the user with the username Admin.

To create a directory or folder use
```
`mkdir <directory_name>`
```

i.e. Create a directory named My-First-Project in Desktop mkdir My-First-Project

Navigate to your created folder. Assuming you are on Desktop, use the following command:
```
`cd My-First-Project/`
```

So your bash terminal path will look like ~/Desktop/My-First-Project

To list and view items use the following command
```
`ls`
```

It will list all files and folders excluding the hidden files and folders. As shown below:

To list and view all files and folders including the hidden ones you add -a attribute to the ls command as below

	`ls -a`

To list files and display their attributes we add the -l attribute to the ls command.

	`ls -l`

Note: You can combine the attributes to list all files and their attributes i.e. as ls -al

You can delete an empty folder using
```
`rm -r <folder_name>`
```

To delete a folder together with its contents we use the rm -r <non-empty_folder_name> command.

Example: Create a folder in you my project folder using the mkdir command, inspect the folder created and its contents, then delete the folder using the rm command:

Steps

Create scripts: mkdir scripts
Navigate to scripts and back to your project folder: cd scripts/ and cd ..
Inspect scripts: ls scripts/
Delete scripts: rm -r scripts/

Note: rm without any attribute will no delete a directory/folder even if empty, the attribute -r tells the command rm that what you're deleting is a directory.

You can copy and paste contents between different folders.

To copy contents moves a duplicate of the files to another location leaving the original intact.

While using the cp command you have to specify the file/contents path and the destination address. Example:

To copy some file named hello.txt to the scripts folder; you need to recreate the folder and create the file in the root directory then copy it to scripts folder in your projects folder

Steps

In your project folder create scripts mkdir scripts
Navigate to your project root folder and create the file hello.txt touch hello.txt
Copy the file to scripts cp hello.txt ~/scripts
Inspect both locations to see that the file exists in both location. ls and ls scripts

Note: You can specify the file path in the cp command if the file is in a different location and the destination path address

i.e. cp <~/path/to/file_to_be_copied.txt> <~/path/to_destination/>

You can move a file or any content completely from the source to an new destination using the mv command.

Example: Move hello.txt file from the project's folder to a new folder named docs

`mv hello.txt docs/

Note: You can also specify the file path in case the files and destination address are in different locations i.e. mv <~/path/from_source/hello.txt> <~/path/to_destination_folder/>

Working With Files

While working in your project you will need to create different files for your project.

The different files will be saved in different directories depending on their type and use.

The organization will help us to achieve a proper project structure, easier to navigate and access our project files.

We will create our files using Git Bash terminal.

To create a file we'll use the touch command.

Create a file named hello-world.txt in your project root directory.

	`touch hello-world.txt`

Use the ls command to confirm your file has been created.
To view the contents of the file we use the cat command, since our file is empty it will display 'nothing'.
```
`cat hello-world.txt`
```
To add contents to our file we use the echo command.

Add the following text to the file hello-world.txt; "Hello, World"

	`echo "Hello, World!" > hello-world.txt`

We use the > to redirect the output to our file. > Rewrites any content in the file.

If you want to add more content to the file use >>, more text will be added to our file.

Example; add the following text to our file "I am happy to learn SSH and Git".

	`echo "I am happy to learn Git and SSH" >> hello-world.txt`

cat hello-world.txt to view the contents of the file.

Editing you file using nano

Nano is an inbuilt text editor in Git Bash.

It helps us to navigate through our files; scripts, text file, .... once we make mistakes.

To open our script or text file we use the nano command in git bash then specify the file we want to open, for example open hello-world.txt using nano:

	`nano hello-world.txt'

There are many more commands for nano that will help you edit your text file. For example the most common commands are:

1. Ctr + O - To save your file

2. Ctrl + X - To exit your nano text editor

3. Ctrl + K - To Cut text in the editor

4. Ctrl + U - To Paste your text

5. Ctrl + G - To find help for you nano editor.

There are many more commands of help that you can use to edit you files in nano editor.

Your First Project

Initialize your first project with git

Before running the command, check to confirm that you are in your project folder using the pwd command.

The pwd command means print working directory it shows your current location with regard to the root directory.

If in your project directory, the path will end with the name of the project folder. I.e. My-First-Project

Use the git init command.

The command is used to initialize our project directory as a git repository.

Git repository structure.

After running the above command, you may notice notification of git initializing an empty git repo...

If you list to view the structure using the ls command you may notice a .git/ folder.

The folder contains Git's internal repository information, which git uses to manage activities such as: push, commits, pull, Branches, project history, repository configurations,....

Checking the project status

	`git status`

Used to show what's happening with your project currently.

It can show things such as untracked files, staged files to be committed yet, if the working tree is clean meaning everything has been committed.

The above show that there is nothing that has been staged for commit, there are three untracked files in the initialized repository.

Staging your project files

	`git add .`

It adds your project files to git for tracking.

Checking on the status of the staged file, you should get such an output with git status command

It prepares all you changes for the next commit.

You can stage a single file by specifying the file/folder you want to stage i.e. git add <file_name.txt>.

You should see almost a similar output when using git status command after staging a single file

Using the . means you stage everything in your project folder.

Commiting you staged files

	`git commit -m "<commit message>"`

Creates a saved checkpoint.

The message should be precise and clear, related to the activity carried out. i.e. "My First Project Using Git Commit"

It does not upload anything to git-hub yet.

Uploading to git-hub

	`git push -u origin <branch_name>

Sends all the committed changes to GitHub. However, in our case we get the above error because we have not linked our local project repo to a git-hub remote repository.

We will be linking our repositories in the next section.

After running this command, you can easily check on the changes whether they reflect on GitHub via your browser.

However, for us we are yet to see these changes. This may not work since we are yet to create a remote repository which we will then connect to our local project in our laptop.

Creating a remote repository

To create a remote repository, follow the following steps:

Login to your git-hub account
In your account click on "Create New Repository"
Enter the name of your Repository as "My-First-Project"
Do not create a README, uncheck the checkbox
Provide a brief descriptions for your project. The description is: "My First Project: From a Local Folder to Git hub Using Git and SSH"
Then click on Create Repository

A new empty repository is created with the name "My-First-Project"

Navigate to your repository
Click on the code section, then click on ssh tab and copy the ssh code

We'll use the ssh code to connect our remote and local repositories before pushing our project.

Connecting our local and remote repositories

Navigate to your git initialized project folder

Type in the following command and thereafter paste the ssh code for your remote repository and hit enter.

	`git remote add origin <your_remote_ssh_code>`

i.e. git remote add origin git@github.com:MakoriNyachaki/My-First-Github-Project.git

Rename your branch

If your remote repository's branch is not main rename it to main

	`git branch -m main`

Check the remote

	`git remote -v`

Push your project to git-hub

	`git push -u origin <branch_name>`

i.e. git push -u origin main this works to upload our committed changes to our git-hub repository.

Summary

An introductory article for learning GIT and SSH. It is thrilling practical exercise for generating ssh keys, working with folders and files, connecting local project folders with remote repositories, and working with git. The introductory article requires one to do further research on so many commands that are available for the different tools we have used here in order to be an expert. Let's learn forward.

I wanted Git to show me what would happen before changing history, so I built it

Tue, 06 Oct 2026 09:55:16 +0000

I use Git every day, but one thing has always bothered me:

when you do something that changes history, a lot of Git tools still basically ask you to understand the command first and trust that the result is what you expected.

I wanted something more visual.

So while building RepoBeam, I added a before/after preview for operations like going back to an older commit.

Instead of clicking the action and hoping I understood it correctly, RepoBeam first shows me what the repository will look like afterwards.

For example, when going back to a commit I can choose whether I want to:

restore the files as normal unstaged changes
restore them already staged
create a new restore commit when rewriting published history would be unsafe

And RepoBeam shows the expected history before I confirm anything.

The idea is simple:

show me what Git is going to do before it does it.

RepoBeam actually started for a different reason.

I used Fork for a long time on Windows. When I started working more on Linux, I tried GitKraken, Sublime Merge, SmartGit, GitButler and a bunch of smaller clients, but I never found one that really felt like the Git GUI I wanted to use every day.

So I started building my own.

Over time it turned into a full Git client with:

local changes and staging
split/unified diffs
commit history and graph
branches and remotes
stashes
guided conflict resolution
before/after Git previews
Coding Sessions

Coding Sessions

This is another part I use a lot now.

When I start working with Codex or Claude, I start a Coding Session in RepoBeam first.

RepoBeam then organizes everything that changes during that session.

I can review the files afterwards, undo one change, bring it back, keep the rest, or undo the entire session.

It does not replace Git or create some separate version-control system. It works with normal Git repositories.

RepoBeam currently runs on Linux and Windows.

Linux builds are available as:

.deb
AppImage
Snap

Private repositories work, no RepoBeam account is required, and the app is free to use including for work.

https://repobeam.com

I released 1.8.3 this week and this is the first time I'm seriously putting RepoBeam in front of developers I don't know.

The thing I'm most curious about:

Would a before/after preview like this actually make you more comfortable with Git history operations, or do you prefer seeing the underlying Git command directly?

Git Submodules: When and How

Mon, 05 Oct 2026 06:47:37 +0000

Contents

Use Cases
Submodules, Subtrees, Mono- or Multirepo?
A Practical Setup Example
- fork.dev
- Terminal
Daily Workflow

Git submodules are a built-in Git mechanism for composing repositories at fixed commits. Unlike a monorepo, separate repositories, or worktrees, they let a root repository record exact revisions of independently owned submodules.

The basic idea is simple: the root repository records a nested repository at an exact commit. The root repository stores the path and remote URL in .gitmodules, and records the submodule commit as a gitlink. A clone can later reconstruct the same combination of repositories.

Use Cases

Briefly: use a submodule when a root repository must record an approved revision of code maintained elsewhere. Here are some useful applications of submodules:

Keep private documentation and deployment configuration in the root repository, with public source code in a submodule.
Pin the exact revision of a shared library maintained and released separately.
Record the approved revisions of independently released services or tools.
Pin a reviewed commit from a maintained fork of an external project.

In product development, the root repository represents the product release context: its documentation, configuration, integration decisions, and approved component revisions. Each submodule represents a component with its own codebase, maintainers, and delivery cycle.

Submodules, Subtrees, Mono- or Multirepo?

Here are some key distinctions, briefly.

A submodule keeps source independent while the root repository records the exact revision used by the product. It fits when public source and private product material must remain separate but form one reproducible product revision.

A subtree copies external source into the root repository. Use it when the root repository should own that source.

A monorepo works well when code, access rules, and release cadence belong together. Nx and similar monorepo tools allow for task execution, caching, project boundaries, and releases conveniently from the single root repository.

A multirepo gives each component its own repository, ownership, and history, but does not by itself record which revisions belong together.

A Practical Setup Example

Consider a product with private documentation and deployment configuration, and public source code maintained in a separate repository.

Root repository: private; contains private material and one or more submodule references.
Submodule: public; contains source code and is its own source of truth.

root/
├── .gitmodules
├── docs/                    # private specifications and operational material
├── deployment/              # private deployment configuration
└── submodule/               # separately owned source repository
    ├── README.md
    └── src/

The root repository tracks .gitmodules and the exact commit recorded at submodule/. The files inside submodule/ belong to the submodule repository.

fork.dev

I use here the Fork Git client. The setup via terminal is in the next section.

Create the local folder structure:

mkdir root
cd root
mkdir docs deployment submodule

In Fork, create a Git repository in root/.
Open submodule/ in Fork and create a separate Git repository there. Add an initial file such as README.md, commit it, and keep this repository independent from root/.
Create two empty repositories in your Git hosting service, for example: private: https://github.com/example/root.git, public: https://github.com/example/submodule.git.
In Fork, add https://github.com/example/root.git as the origin remote of the root/ repository.
Add https://github.com/example/submodule.git as the origin remote of the submodule/ repository, then push its initial commit.
Return to the root/ repository. In the sidebar, right-click Submodules → Add New Submodule. Enter repository URL: https://github.com/example/submodule.git, local path: submodule. Fork registers the existing local repository as the submodule.
Commit .gitmodules and the new submodule gitlink in the root repository, then push the root repository to its private origin.

Terminal

The same setup from a terminal, creating both repositories locally first and then attaching their remotes:

# Create the local folder structure.
mkdir root
cd root
mkdir docs deployment submodule

# Initialize the private root repository.
git init -b main
git remote add origin https://github.com/example/root.git

# Initialize the public submodule repository.
cd submodule
git init -b main
echo "# Submodule" > README.md
git add README.md
git commit -m "Initial commit"
git remote add origin https://github.com/example/submodule.git
git push -u origin main

# Return to the root repository and register the existing local repository
# as a submodule.
cd ..
git submodule add --force https://github.com/example/submodule.git submodule

# Commit the root repository state.
git add docs deployment .gitmodules submodule
git commit -m "Add submodule"
git push -u origin main

Daily Workflow

Treat the submodule commit as a dependency lock. Change code in the submodule repository, then deliberately update the root repository's pointer.

With that workflow, the repositories keep their separate ownership, history, and visibility, while the root repository still records the exact combination that belongs to the system.

Example:

Doble-click on Submodules->submodule repository to open its tab. Add its source files, stage them, commit them, and push them to the public origin.
Return to the root repository. Add private files under docs/ and deployment/. Stage docs/, deployment/, commit them, and push them to the private origin.

For private documentation or configuration changes, work in the root repository directly. For source changes, commit and push them in the submodule first, then commit the changed submodule reference in the root repository.

When cloning later, use recursive initialization:

git clone --recurse-submodules <root-repository-url>

For an existing clone, use:

git submodule update --init --recursive

References: Git submodule documentation and Git submodules guide.

Handling Git Merge Conflicts in Multi-Agent Worktrees

Sun, 04 Oct 2026 06:04:12 +0000

Scaling multi-agent coding swarms using Git worktrees allows multiple autonomous agents to write code simultaneously without disk exhaustion. However, the throughput bottleneck rapidly shifts to the integration boundary. When dozens of agents modify repositories concurrently, development teams face textual merge conflicts, the hazard of automated models misinterpreting conflict markers, and silent semantic drift where code merges cleanly but breaks runtime contracts.

The Integration Wall in Multi-Agent Coding

Generating code in isolated worktrees is straightforward, but converging those changes back into a shared canonical branch creates friction. The primary challenges include textual merge conflicts when two agents touch the same configuration file or route index, and silent semantic drift where a merge succeeds textually while introducing runtime failures because Agent A updated a function signature while Agent B called the deprecated version.

The Myth of LLM Merge Conflict Resolution

Prompting an autonomous coding model to fix git conflicts is inherently dangerous. Models frequently hallucinate resolution logic, drop critical changes committed by peer agents, or accidentally preserve broken conflict markers in production builds. Instead of treating the language model as a conflict resolution tool, architectures must prevent conflicts before they reach the merge stage or enforce rigid programmatic validation.

Path Reservation Architecture

Instead of dealing with conflicts after the fact, the orchestrator implements pessimistic resource locks. When a task is dispatched to an agent, its target file paths and dependencies are claimed. If a subsequent task requires writing to overlapping files, the orchestrator enforces serialized dependency ordering rather than parallel execution. For a related implementation, see Agent Orchestrator Vs Model Router.

{
  "task_id": "task-8842",
  "assigned_agent": "agent-beta",
  "worktree_path": "/var/lib/worktrees/agent-beta",
  "reserved_paths": [
    "src/api/router.ts",
    "src/models/user.ts"
  ],
  "lock_status": "acquired"
}

The Serialized Merge Queue Blueprint

Coding runs in parallel across isolated worktrees, but merging into the canonical branch is strictly single-lane. When an agent finishes its work, the orchestrator rebases its branch onto the updated main branch, executes automated tests in the rebased context, and performs a fast-forward merge only if all checks pass. If an automated rebase encounters merge conflicts or test regressions, the system fails closed rather than permitting the agent to guess at conflict markers.

Conclusion

Integrating code from concurrent AI coding agents requires moving past the illusion that large language models make good merge conflict resolvers. By combining path reservation at the dispatch boundary with a serialized merge queue and fail-closed rebase testing, teams can maintain a stable canonical branch without sacrificing the throughput benefits of parallel worktree execution.

Shared Git State in Parallel Agent Worktrees

Fri, 02 Oct 2026 02:00:46 +0000

When deploying multiple AI coding agents across isolated Git worktrees, it is common to assume complete independence. While worktrees provide separate filesystems, working directories, and HEAD pointers, they share a single underlying object database and branch namespace. This shared architecture introduces subtle failure modes when multiple agents execute git commands concurrently. Understanding these shared state hazards prevents unexpected ref corruption and silent failures during automated workflows.

The Shared Ref Layer and Mutable State

The core problem stems from how Git structures worktrees. Although each worktree maintains its own checked-out files and staging index, all worktrees in a repository point to the same .git directory. The object database, reflogs, and branch references are globally mutable across the entire repository. When one agent executes a destructive command like git reset --hard or git branch -D, the mutation immediately propagates to the shared object store. Sibling worktrees referencing those same commits or branches observe the change instantly, which can break active diffing, rebasing, or logging operations.

Consider a scenario where Agent A and Agent B are spawned in parallel. If Agent A performs a destructive force reset on a shared tracking branch, Agent B can experience sudden ref invalidation. The following table outlines the primary failure taxonomy, their triggers, their blast radius, and their corresponding defensive patterns.

Failure Mode	Trigger	Blast Radius	Defensive Pattern
Cross-Worktree Ref Mutation	`git reset --hard` or `git branch -D` inside an active worktree	Immediate invalidation of refs in sibling worktrees	Restrict agents to non-destructive commands; delegate all ref pruning to the orchestrator
Branch Creation Race	Concurrent `git worktree add` calls attempting to create identical branch names	Silent failure or hard error in the second agent spawn	Use orchestrator-assigned unique suffixes or agent-id branch prefixes
Reflog Contamination	Frequent concurrent commits and fast-forwards to the same local branch	Confused log histories and difficult rollbacks	Isolate working branches strictly per agent instance	For a related implementation, see Git Worktrees Parallel Ai Coding Agents.

Preventing Branch Name Collisions

Branch name collisions represent another frequent point of failure in automated orchestration. Git prohibits checking out the same branch in more than one worktree simultaneously. If an automation script spawns two agents and both attempt to create or check out agent/fix-login, the second operation fails. Relying on agents to pick their own names or depending solely on static task descriptions often results in race conditions.

To eliminate this collision window at the naming layer, branch creation must be owned by the orchestrator prior to spawning the agent. Injecting a short unique suffix into the branch name ensures uniqueness without sacrificing readability.

#!/usr/bin/env bash
set -euo pipefail

TASK_NAME="fix-login"
UNIQUE_SUFFIX="a7b3"
BRANCH_NAME="agent/${TASK_NAME}-${UNIQUE_SUFFIX}"
WORKTREE_PATH=".worktrees/${TASK_NAME}-${UNIQUE_SUFFIX}"

git branch "${BRANCH_NAME}" main
git worktree add "${WORKTREE_PATH}" "${BRANCH_NAME}"

echo "Spawned agent in worktree at ${WORKTREE_PATH} on branch ${BRANCH_NAME}"

This script demonstrates how an orchestrator can provision an isolated worktree with a collision-safe branch name before handing execution over to an agent process. By preventing agents from executing branch creation or deletion commands directly, the repository maintains structural integrity.

Securing Multi-Agent Workflows

Managing shared Git state effectively requires treating the object database as a global resource that only a centralized orchestrator should modify. Agents should be constrained to local commits within their assigned branch. Once an agent completes its task, the orchestrator verifies the changes, merges the results, and handles branch deletion during the cleanup phase. Adopting this defensive lifecycle prevents race conditions and ensures that parallel workflows scale reliably without stepping on each other refs.

How to Show Engineering Ownership When the Repositories Are Private

Sat, 19 Sep 2026 19:40:20 +0000

Originally published on 30 July 2026 at efe-genc-portfolio.vercel.app. That version is the maintained one; the figures below are measurements taken on the dates stated and are not updated here.

I have spent more than four years shipping production software, and I have no public repositories worth showing you. Everything substantial I have written at work lives in private repositories that belong to the companies I wrote it for, and confidentiality obligations do not lapse when a role ends. So I cannot hand you the code, and I am not going to.

I do not say that to sound careful. An engineer who sends a prospective employer another company's source code has told you exactly what they will do with yours. The restraint is part of what you are assessing, and I would want the same restraint applied to my own work later.

That leaves a real problem. "I was the principal author of the web application" and "I contributed to the web application" are the same sentence to a reader who cannot check either one. Most engineering CVs resolve this by getting louder. The only honest resolution I have found is to publish the measurement method instead of the artefact, in enough detail that someone who knows the tools can judge the figure on its own terms without ever seeing the repository.

Here is the method I used, what it does badly, and the places where applying it forced me to shrink a claim I would have preferred to keep.

Three measurements, in increasing order of rigour

The first is the all-branch commit count: total authored activity. Do not use it. It counts abandoned branches, spikes and experiments, and it inflates in favour of whoever is most willing to commit. It is the number that makes contribution graphs look impressive and says the least about a codebase.

The second is the production-branch commit count, scoped to tenure: what reached customers while you were there. This is better, because it excludes work that never shipped, and because scoping to tenure stops you from taking credit for years of history that predate you, or being penalised for them. But it still counts commits, and a commit is a unit of activity, not a unit of code. Commit share rewards granular committers and punishes people who work in larger increments. It is the weakest of the three, and unfortunately the easiest to produce, which is why it is the one people quote.

The third is git blame on the production branch: which lines are alive in production today, and who wrote them. This is the authoritative one, because it measures surviving authorship. The code was written, shipped, survived every later refactor by everyone else, and is running now. Its weakness is that it is slow, so it has to be sampled.

Two details make the blame figure defensible, and they carry the whole exercise.

The flags. I ran git blame -w -M against the production branch. -w ignores whitespace-only changes and -M detects lines moved or copied within a file. Both make the result more conservative rather than more flattering, because reformatted or relocated code is attributed to whoever originally wrote it instead of whoever last touched it. If I had wanted a bigger number I would have left both flags off, and anybody who knows the command can verify that without access to anything.

The sampling. Deterministic, every Nth file across the sorted file list. I did not hand-pick a directory, and I did not take a random draw that I could have re-rolled until it flattered me. Anyone with the same repository can reproduce it. Sampling by directory is where this kind of measurement usually goes wrong, because directories are exactly where authorship clusters.

What that produced, and why the gap is the interesting part

At Cendra, where I was one of two founding engineers, blame analysis on a deterministic one-in-seven sample of the production TypeScript sources (several hundred files) attributes 84.7% of surviving frontend code to me, with the remainder spread across eight other contributors. My production-branch commit share over the same period, scoped to my tenure, is 80.7%.

The script is public now as surviving-lines: one file, no dependencies, the same deterministic sample and the same git blame -w -M, with the caveats printed under every table so the number cannot travel without them. The whole report, six figures with the command behind each and a hash that anyone with the repository can verify, is workproof.

The gap between those two numbers is the claim, and it points in the direction most people would not expect. My share of surviving lines is higher than my share of commits, which means code written by others was disproportionately replaced by code written by me. I did more than add volume to a growing surface; I rewrote and consolidated the one that was already there. That is an argument about architectural ownership rather than throughput, and it is why I describe myself as principal author instead of the person who happened to commit the most.

Had the ratio gone the other way, with commit share above blame share, the honest reading would be that I produced a lot of code that other people later replaced. That is a real outcome and it happens. A method that could not have shown it would not be a measurement.

Some figures need no method at all. Every commit to the ios/ and android/ projects across the entire history of the repository is mine, 47 and 28 respectively, along with the Capacitor configuration and the Playwright end-to-end suites at 11 of 11 each. No other author has ever committed to those paths. That is the least arguable claim I have, and it is arithmetic rather than analysis.

I measured all of these while I held authorised access, using ordinary git invocations. I am not offering to demonstrate them live, and you should be wary of anyone who would. Opening a former employer's private repository in a screen share is a breach in itself.

The method is most useful when it makes you shrink things

The uncomfortable half of publishing a method is that it applies to the parts of the work you were less central to, and it does not let you round them up.

The same blame analysis run against the production C# sources attributes 23.2% of surviving backend code to me, with a 30.9% commit share over my tenure. I joined the backend roughly six months into a twelve-month tenure. It had been under active development for eighteen months before I touched it, by engineers who are still there. So the accurate sentence is that I was a substantial contributor to a codebase I joined late, and I was not its architect. I have tried hard not to imply otherwise anywhere.

Where that contribution sits turns out to be more informative than the total. My share of commits since joining runs highest in the test suite at 83.2%, the domain services at 53.6% and the event-processing consumer at 55.4%, and lowest in the infrastructure at 24.1%, the core domain at 20.8% and the CQRS feature handlers at 16.6%. Low in shared CRUD surfaces, high where architectural judgement was required. I was not the highest-volume backend contributor. I owned the parts that needed design, and the test suite the rest of the team relied on. Other contributors' shares are their own information, and they are not mine to publish.

Across all four repositories, scoped to my tenure, the combined figure is 5,717 of 10,402 production-branch commits, or 55.0%. That is the most conservative aggregate available, and I record it for that reason, but I would not lead an argument with it. A single number that spans a frontend I was principal author of and an integration service I touched occasionally is not really a claim about either. Any aggregate over unlike repositories describes them worse than the per-repository figures it averages. That is why the breakdown above exists, and why the 84.7% is the number I would defend first.

The method cannot measure two more boundaries, but honesty requires them.

The core AI architecture at Cendra was not mine. Our AI engineer owned the LangGraph services, the agent workflows and the RAG pipelines. I built the product layer those capabilities were surfaced through (agent configuration, the knowledge base, the agentic rule-authoring interface and the in-product assistant) and the transport between the two, over AG-UI, server-sent events and the realtime hub. I contributed to how the rule and guardrail semantics were shaped, because building an interface through which a non-technical operator expresses a rule an engine will enforce requires understanding those semantics as deeply as the person implementing the enforcement. But I did not architect the orchestration. "I worked on the AI product" is the easiest sentence in this industry to say and the least informative.

Cendra's product-level metrics are not mine either. Automation rates and platform reach are company figures published by the company. I contributed to the systems behind them. I did not measure them, and presenting a company outcome as a personal one is the specific move that makes every other number on a CV suspect.

At ReadyFly, a part-time founding-engineer role, I have commit shares and nothing better: 157 of 209 commits to the web application, roughly three quarters, and I made the first one; and 31 of 209 to the Python API. So I say principal author of the first and contributor to the second, and I do not dress the 15% up. The AI models themselves, semantic matching and candidate evaluation, were owned by the team's AI engineer. I built the product layer they were surfaced through, and the browser side of that story is in An Interview Inside the Browser.

Commit share is the weakest of the three measurements. When it is the only one available, the right response is to say so, rather than to present it in the same voice as a blame figure.

What closes the gap

Method plus disclosure gets you to a claim that can be judged. It does not get you to a claim that has been independently confirmed, and I do not think any amount of self-published measurement does.

Three things do. Process artefacts that exist independently of my description of them: 255 design specifications, 207 implementation plans and 17 production runbooks, alongside 377 production releases coordinated across four repositories over 239 active development days in a twelve-month tenure. Two Cendra co-founders who have agreed to act as references and can confirm scope and ownership without me in the room. And an offer that costs me nothing to make, because it is the part I am confident about: a walkthrough of the systems that are mine, line by line, including the parts I would now build differently.

The measurements are there so the conversation can start somewhere better than mutual assertion. They are not the evidence. They describe how I would go about finding out, and I have published them so that you can disagree with them.

The Three States of a Secret: Tracked, Ignored, and the One That Ships It

Mon, 14 Sep 2026 18:23:38 +0000

Every Git tutorial teaches three states. Modified, staged, committed: the working directory, the staging area, the repository. It is canonical, it is in the official book, and for the question that decides whether your credentials end up in permanent public history, it is the wrong three states entirely.

The axis that matters for a secret is different. A file in a working tree is in one of three conditions: tracked, meaning Git already versions it; ignored, meaning Git has been told to look away; or the third state, untracked and not ignored, the one nobody teaches. A file in the third state shows up in every status listing. It is included in every git add . and git add -A. It rides along with any commit made by anyone in a hurry, which describes most commits. The first two states are decisions. The third state is an accident waiting for a keystroke.

Last week we found a credential living in exactly that state, in our own shared repository.

A list with a gap

The file was a QA auto-login token: a per-machine secret, minted automatically, that lets a local test harness skip a login screen. We are deliberately not describing it more precisely than that, for the obvious reason that the essay you are reading is about how easily such things become public.

What made the find instructive was not the token. It was the neighborhood. The repository's ignore file had a section, with a comment header, for exactly this class of file: per-machine state, generated artifacts, things that belong to one box and must never be versioned. The token's class-siblings were all correctly listed there. A deploy marker: ignored. A generated test-state directory: ignored. The token itself: absent from the list. Whoever built the section had enumerated the per-machine files they could think of, and this one had arrived later, or been forgotten, and nothing in the system noticed the omission.

So the failure was clerical, not conceptual. Nobody misunderstood security. Nobody made a bad call. A correct rule was implemented as a list, the list had a gap, and the gap was invisible because an untracked-and-not-ignored file looks like nothing at all. It does not fail a build. It does not trip a scanner that only reads committed content. It sits in the status listing of a busy repository, camouflaged among the genuinely new files that appear and disappear all day, one add -A away from being versioned, pushed, and preserved.

That phrase, one commit away from permanent, sounds like rhetoric. It is not, and the reason it is not is worth two minutes of your attention.

Permanent means permanent, by design

In 2024, researchers at Truffle Security documented what they called Cross Fork Object Reference: on GitHub, a commit made to any repository in a fork network can be accessed from any other repository in that network, by supplying the commit hash directly. The consequences are stranger than they sound. Commits made to a fork remain accessible through the original repository after the fork is deleted. Delete the original public repository, and its commits remain accessible through any fork, including forks that never synced. Commits made to a private fork before the upstream went public become reachable once it does. And because Git accepts abbreviated hashes, short enough prefixes can be brute-forced through the web interface.

To demonstrate, the researchers reviewed three commonly forked public repositories from a major AI company and found forty valid API keys in commits that existed only in deleted forks. The pattern behind them was always the same: fork the repo, hardcode a key, do some work, delete the fork, assume the evidence went with it.

GitHub, responding through its vulnerability disclosure program, said the behavior is an intentional design decision and is working as expected. Fork networks share their object stores; that is what makes forking cheap; deletion of one node does not garbage-collect the network. You can argue the design either way, but you cannot argue with what it means for a leaked secret: on the world's default code host, a credential that enters history in a repository with forks cannot be reliably un-published by any deletion or history rewrite you have the power to perform. The scrub tools clean your copy. The network remembers.

Which reframes the little file in our status listing. The distance between "sitting untracked on one machine" and "recoverable forever by strangers" was not a security boundary. It was one inattentive command by any collaborator, on any morning.

The scale of the middle state

If this were rare, it would be an anecdote. GitGuardian's State of Secrets Sprawl report for 2026 counted 28.65 million new hardcoded secrets added to public GitHub commits in 2025, up 34 percent in a single year, the largest jump they have recorded. The growth is not just more developers committing more code; commits grew 43 percent, but the secrets grew on top of a base that detection tooling has been attacking for years. Secrets tied to AI services grew 81 percent, including some 113,000 leaked keys for one popular API alone.

Two of the report's findings matter more than the raw count.

First: private repositories are roughly six times more likely than public ones to contain hardcoded secrets. Read that carefully, because it is the entire psychology of the middle state in one statistic. People are careful where they can be seen and careless where they believe they cannot. The private repo feels like a drawer; developers treat it like one. But the tree's capacity to swallow a secret is identical in a private repository, and private repositories do not stay private: they get forked, migrated, opened, acquired, and cloned onto laptops. The QA token in our tree was "only" on a shared internal repo. Six-x is what "only internal" does to discipline, measured at population scale.

Second: leaked credentials do not die. Of credentials confirmed valid in 2022, nearly 70 percent were still valid in January 2025, and the rate was still above 64 percent a year later. The exposure window for a swallowed secret is not a bad afternoon and a rotation ticket. Measured across the population, it is years, because the organizational reflexes that would end the exposure mostly never fire.

Put the two datasets together and the middle state stops looking like a pedantic edge case. Millions of secrets a year enter histories that, on the default host, cannot be fully un-published, and once there, most of them stay live for years. Every one of them passed through the third state on the way.

The mirror

One more number from the same report, and it is about us. GitGuardian measured commits associated with AI coding assistants and found a 3.2 percent secret-leak rate, against a 1.5 percent baseline across public commits generally. Roughly double. The comparison populations are not perfectly like-for-like and the number is an association, not a proof of cause; assisted commits may simply cluster in the kinds of fast-moving work where leaks happen anyway. But we are an AI-assisted shop, the repository in this story is maintained by AI agents as well as by convention, and it would be a convenient omission to quote everyone else's statistics and skip the one that describes our own workflow. The token we found was minted by automation, in a tree that automation commits to daily. Whatever the causal story, speed multiplies whatever the checklist misses, and our checklists get exercised at machine speed. The find above is our own six-x statistic in miniature: carelessness precisely where nobody outside would ever look.

Deny by default, and the scope of the fix

Here is what we did not do: we did not rotate the token. Before anyone quotes the incident-response handbook, notice the scope. This credential never left the third state. Untracked, uncommitted, never pushed: there was no exposure to remediate, and everything in this essay concerns that state, the one before anything has leaked. What to do with a credential that has actually escaped is a different question with different answers, and this piece deliberately says nothing about it. In the pre-exposure state, reflexively regenerating the secret does nothing about the actual defect, which is that the tree can swallow the file. Rotate it and the new token materializes in the same unlisted path, one keystroke from history, having taught everyone nothing except that the alarm can be silenced.

The fix for the state is structural, and it is the same fix the six-x statistic points at: stop depending on someone remembering to extend a list. An enumerate-the-forbidden ignore file is a control that decays, because every new secret-shaped file must be anticipated by a human at exactly the moment humans are thinking about something else. The durable versions are deny-by-default. Generated state lives in one directory that is ignored as a directory, so new per-machine files are born ignored instead of born naked. Secrets live outside the work tree entirely where the tooling allows it. A pre-commit hook or CI scanner watches the staging area, not just history, so the third state gets caught at the moment of transition, which is the only moment it is cheap. And the status listing itself is treated as a signal: a repository whose git status is habitually noisy is a repository where one more untracked file is invisible, and invisible is the whole problem.

None of this is exotic. That is rather the point. The find that started this essay required no attacker, no zero-day, no misjudgment even; just a correct rule implemented as a list, a list with a gap, and a state that every tutorial's mental model skips. Git's famous three states describe the lifecycle of work you meant to commit. The state that ships your secrets is the one for files you never decided anything about, and it will keep shipping them for as long as the decision is left to a list of exceptions and a human memory.

Check your own status listing today. Not the history: the listing. Count the files that are neither tracked nor ignored, and ask, for each one, what happens on the day someone in a hurry types git add -A. If the answer for any of them is "that must never be committed," you are one omitted line away from a statistic that stays valid for years. The line costs ten seconds. The middle state is the only place it can still be written that cheaply.

Sources

· GitGuardian, The State of Secrets Sprawl 2026 — the 28.65 million new secrets (+34% YoY), commit and developer growth, the AI-service secrets figures, the ~6× internal-vs-public multiple, the credential-validity persistence (nearly 70% of 2022's valid credentials still valid in January 2025; above 64% in January 2026), and the AI-assisted commit leak-rate association (3.2% vs 1.5% baseline).

· Truffle Security, Anyone can Access Deleted and Private Repository Data on GitHub — the Cross Fork Object Reference write-up: the three persistence paths, the forty valid API keys recovered from deleted forks, and GitHub's disclosure-program response that the behavior is an intentional design decision.

· Pro Git (git-scm.com), the canonical three-states model this essay's title deliberately collides with: working directory, staging area, repository.

· The QA-token find is our own, from a shared internal repository, described generically throughout for the reason the essay gives.

Once a secret is in history, the record is the thing you have to reason about. Chain of Consciousness records what an agent actually did, step by step, so the reading and the decision live in the same artifact.

Hosted Chain of Consciousness · Verify a record

pip install chain-of-consciousness · npm install chain-of-consciousness

Building KOS: A Journey Through Zero Dependencies (And the Bugs That Taught Me Everything)

Tue, 08 Sep 2026 12:13:13 +0000

I didn't set out to reject go get. I just wanted to build something clean. But somewhere between the first snapshot corruption and the fourth complete rewrite, I realized: zero dependencies wasn't a constraint. It was a feature.

This is the real story of KOS—what I built, what broke, why I fixed it the way I did, and how you can use it yourself.

What is KOS?

KOS is a portable, encrypted version control system. It's not trying to replace Git. It's trying to be something Git isn't:

Single file: Everything lives in one main.go (~2000 lines)
Zero dependencies: 100% Go standard library
Encrypted: AES-256-CFB with HMAC-SHA256 integrity
Portable: Runs from a USB stick, no installation
Simple: kos init → kos save "message" → kos view

It stores your project snapshots in a global vault (~/.kos-global/) indexed by UUID. No Git databases. No complex merge logic. Just snapshots and timelines.

Getting Started: How to Use KOS

Installation

git clone https://github.com/kosmoscpp/kos
cd kos
make install  # Linux/Mac
# or: build.bat  # Windows

That's it. One binary. No dependencies to install. You can even compile it on a machine without Go and ship the binary to another machine.

Basic Workflow

Initialize a project:

kos init
# ✓ Initialized empty KOS repository in /home/user/.kos-global/abc123...
# Project UUID: abc123-def456-ghi789-...

Create snapshots:

kos save "Initial commit"
kos save "Added authentication"
kos save "Fixed bug in auth flow"

View your timeline:

kos view

Output:

╔══════════════════════════════════════════════════════════╗
║                     KOS TIMELINE                         ║
╚══════════════════════════════════════════════════════════╝

  ● abc1e2f1 ┃ Jan 08, 14:32 (just now) ┃ Fixed bug in auth flow
  │           ┃  42 files
  │
  ● a2d3f4b5 ┃ Jan 08, 14:15 (15 mins ago) ┃ Added authentication
  │           ┃  41 files
  │
  ● 8c7e9a0b ┃ Jan 08, 12:00 (2 hours ago) ┃ Initial commit
  │           ┃  40 files
  └── (End of history)

Compare snapshots:

kos diff abc1e2f1 a2d3f4b5
# Shows: + Added (0), ~ Modified (2), - Deleted (0)

kos diff abc1e2f1 a2d3f4b5 auth.go
# Shows line-by-line diff for auth.go

Tag releases:

kos tag v1.0
kos tag stable abc1e2f1  # Tag a specific snapshot

Restore your work:

kos checkout abc1e2f1                    # Restore entire snapshot
kos checkout abc1e2f1 src/main.go        # Restore single file
kos checkout v1.0                        # Restore by tag
kos checkout HEAD~3                      # Go back 3 commits

Encrypted snapshots:

kos save --encrypt "Secret credentials"
# Password: ****
# Confirm: ****
# 🔐 Saved encrypted snapshot: Secret credentials (15 files)

kos share abc1e2f1  # Export as snap_abc1e2f1.tar.gz.enc
# Can email/USB/cloud this file. Recipient loads with:
kos load snap_abc1e2f1.tar.gz.enc
# Password: ****

Project management:

kos projects           # List all projects in global store
kos rename "my-blog"   # Rename current project
kos stats              # Show project statistics
kos search "refactor"  # Search commit messages

The Bugs (And Why They Matter)

This is where it gets real. Because building from scratch means building through everything.

Bug #1: HEAD Recognition Fails (The Identity Crisis)

Early on, I implemented KOS to share and diff by snapshot ID. Simple, right?

kos share HEAD        # Error: Snapshot 'HEAD' not found
kos diff v1.0 v1.1   # Error: Snapshot 'v1.0' not found

Only raw IDs like 18d03947 worked. Tags and HEAD references were rejected.

The root cause: I wrote separate lookup functions that did direct ID matching instead of using a reference resolver:

// WRONG: Direct lookup, doesn't handle special refs
func findSnapshot(id string) *Snapshot {
    for i := range manifest.Snapshots {
        if manifest.Snapshots[i].ID == id {
            return &manifest.Snapshots[i]
        }
    }
    return nil
}

The fix: I extracted reference resolution into a single function that handles all cases:

// CORRECT: Handles IDs, tags, HEAD, and HEAD~N
func resolveRef(ref string) *Snapshot {
    snaps := manifest.Snapshots
    if ref == "HEAD" {
        return &snaps[len(snaps)-1]
    }
    if strings.HasPrefix(ref, "HEAD~") {
        parts := strings.Split(ref, "~")
        var offset int
        fmt.Sscanf(parts[1], "%d", &offset)
        idx := len(snaps) - 1 - offset
        if idx >= 0 && idx < len(snaps) {
            return &snaps[idx]
        }
    }
    for i := range snaps {
        if snaps[i].ID == ref || snaps[i].Tag == ref {
            return &snaps[i]
        }
    }
    return nil
}

Now every command uses resolveRef(). Git-like references work everywhere.

What I learned: Centralize your logic. Don't repeat the same lookup in ten places. You'll catch edge cases faster and users won't hit weird state machines.

Bug #2: Encryption Produces Garbage (The Defer Nightmare)

Encrypted snapshots were completely corrupted. Trying to load them:

Error: unexpected EOF when trying to decrypt

I was encrypting an incomplete file.

The root cause: In cmdSave(), I used defer for everything:

// WRONG: Defer happens at function exit, but we encrypt before that!
file, err := os.Create(filepathTar)
defer file.Close()

gzw := gzip.NewWriter(file)
defer gzw.Close()

tw := tar.NewWriter(gzw)
defer tw.Close()

// ... add files to tar ...

if encrypt {
    encryptFile(filepathTar, encPath, password)  // File still open!
    // Defer hasn't run yet. File is incomplete. We're encrypting garbage.
}

The file was still being written when I tried to encrypt it. The tar writer hadn't flushed. The gzip writer hadn't compressed. The file wasn't closed.

The fix: Explicit close order before encryption:

// CORRECT: Close in dependency order before encryption
tw.Close()      // Tar closes first
gzw.Close()     // Gzip flushes compression
file.Close()    // File closes last

if encrypt {
    encryptFile(filepathTar, encPath, password)  // Now it's complete
}

This was a painful lesson in writer layering. Each writer depends on the one below it. You have to close from the top down.

What I learned: Don't let defer fool you into false security. When you have layered resources (writer → compressor → file), you need explicit, ordered cleanup. defer is great for simple cases. For complex ones, be explicit.

Bug #3: Encrypted Load Shows Zero Commits (The Skip Logic Backfire)

When loading encrypted snapshots:

kos load snap_abc123.tar.gz.enc
# ✓ Loaded encrypted project successfully!
# Commits: 0  ← WRONG! Should be 5

All the commits disappeared.

The root cause: The extract function had smart logic to skip .kos/ metadata when extracting:

// This is correct for normal use
if strings.HasPrefix(header.Name, ".kos/") {
    continue  // Skip metadata files
}

But the encrypted load code needed to read .kos/manifest.json to show how many commits existed. Since it was being skipped, the manifest was empty.

The fix: Use a different extraction function for encrypted loads that doesn't skip:

// extractFileFromTar reads directly from tar without skip logic
manifestContent, err := extractFileFromTar(decryptedPath, ".kos/manifest.json")
json.Unmarshal([]byte(manifestContent), &embeddedManifest)

Now encrypted snapshots preserve their full history.

What I learned: When you have branching logic (normal extract vs. encrypted load), they need different paths. Don't let one code path's assumptions break another's.

Bug #4: Password Masking Without x/term (The Syscall Journey)

I wanted masked password input (asterisks instead of plaintext). The easy way: golang.org/x/term. But that breaks zero dependencies.

So I went low-level. POSIX syscalls. SYS_IOCTL. Terminal state manipulation.

func readPassword() string {
    fd := int(os.Stdin.Fd())
    oldState, err := getTerminalState(fd)
    if err != nil {
        // Fallback if we can't control terminal
        var password string
        fmt.Scanln(&password)
        return password
    }
    
    newState := oldState
    newState.Lflag &^= syscall.ECHO  // Disable echo
    setTerminalState(fd, newState)
    defer setTerminalState(fd, oldState)
    
    var password []byte
    buf := make([]byte, 1)
    for {
        n, err := os.Stdin.Read(buf)
        if err != nil || n == 0 || buf[0] == '\n' {
            break
        }
        if buf[0] == 127 || buf[0] == 8 {  // Backspace
            if len(password) > 0 {
                password = password[:len(password)-1]
                fmt.Print("\b \b")  // Visual backspace
            }
        } else {
            password = append(password, buf[0])
            fmt.Print("*")
        }
    }
    return string(password)
}

func getTerminalState(fd int) (syscall.Termios, error) {
    var state syscall.Termios
    _, _, errno := syscall.Syscall6(
        syscall.SYS_IOCTL,
        uintptr(fd),
        uintptr(syscall.TCGETS),
        uintptr(unsafe.Pointer(&state)),
        0, 0, 0,
    )
    if errno != 0 {
        return state, errno
    }
    return state, nil
}

The tricky part: One wrong flag bit and users see their passwords on screen. The POSIX terminal model is finicky. This code works on Linux. Windows POSIX layer might have issues (but that's acceptable for a hackathon).

What I learned: Sometimes the "easy" dependency exists for a reason. But understanding the low-level mechanism? That's worth more than convenience. Now I know how terminal echo works. I know what TCGETS and TCSETS do. I know the bitfield layout of Termios.

Bug #5: The PBKDF2 Myth (And Correcting a Senior Engineer)

During review, someone asked: "Why SHA256 for key derivation instead of PBKDF2?"

They said: "It's in the standard library."

It's not.

crypto/pbkdf2 doesn't exist in stdlib. It's in golang.org/x/crypto, which is external. I had to correct them.

// This is what I use (stdlib)
func deriveKey(password string) []byte {
    hash := sha256.Sum256([]byte(password))
    return hash[:]
}

Felt weird correcting a senior engineer, but I was right. I triple-checked. go doc crypto/pbkdf2 returns nothing.

The choice: SHA256 is fast. PBKDF2 is slower (which is good for passwords—more resistant to brute force). But for a hackathon tool, the trade-off is acceptable. And it keeps zero dependencies.

What I learned: Don't assume. Don't trust memory. Actually verify what's in the standard library. And sometimes you do know things that others don't.

Bug #6: Ghost Projects In ~/.kos-global/ (The Cleanup Problem)

After months of testing:

ls ~/.kos-global/
abc123-def456-...
import-test-1
import-test-2
my-awesome-project-v1
my-awesome-project-v2
test-uuid-alpha
test-uuid-beta
... fifteen more orphaned directories

Each test run created new UUIDs. Each UUID got added to projects.json. But I never deleted old ones.

The root cause: During testing, I created projects, then deleted them locally, but their entries in projects.json remained. Then their directories stayed in the global store, orphaned and forgotten.

The fix: Had to manually:

rm -rf ~/.kos-global/test-uuid-*
rm -rf ~/.kos-global/import-test-*
vim ~/.kos-global/projects.json  # Remove orphaned entries

Then rebuild the index.

What I learned: Testing creates state. State accumulates. You need cleanup procedures or eventual garbage collection. In production, KOS should have a kos gc (garbage collect) command to clean up orphaned projects.

The Real Lessons

1. Writer Layering Matters

Gzip writes to a tar writer. The tar writer writes to a file. You have to close them in order: tar → gzip → file. Not all at once with defer.

2. Centralize Reference Resolution

Don't lookup snapshots in ten places. Do it in one place (resolveRef). Now HEAD works everywhere. Tags work everywhere. No weird edge cases.

3. Skip Logic Can Break Assumptions

Your extract function skips .kos/ files? That's correct for normal use. But encrypted loads need them. Different paths for different use cases.

4. Syscalls Teach You Real Things

Using golang.org/x/term is easy. Using syscall.Syscall6 with TCGETS is harder. But now I understand terminal echo at the OS level. That knowledge sticks.

5. Test State Accumulates

Build testing cleanup into your workflow. Delete projects between tests. Clean up projects.json. Otherwise you end up with fifteen ghost projects.

Why Zero Dependencies Was Worth It

I could have used:

github.com/urfave/cli for CLI parsing
golang.org/x/term for password masking
github.com/fatih/color for colors
github.com/google/uuid for UUIDs
github.com/sergi/go-diff for diffs

Each would have saved time on that specific feature. But:

I wouldn't have understood how any of them work
The binary would be much larger
The attack surface (for a security tool!) would be huge
I wouldn't have learned anything
Deployment would be more complex

Instead, I built a 4.2 MB binary that runs anywhere. I understand every line. I can audit it myself. I can deploy it to air-gapped networks. I can ship it on a USB stick.

How to Try It

# Clone and build
git clone https://github.com/kosmoscpp/kos
cd kos
go build -o kos .

# Initialize a project
mkdir my-project
cd my-project
../kos init

# Save some work
echo "Hello, KOS" > readme.md
../kos save "Initial commit"

# See the timeline
../kos view

# Make a change
echo "Hello, KOS with updates!" > readme.md
../kos save "Updated readme"

# View timeline again
../kos view

# Check what changed
../kos diff <snapshot-id-1> <snapshot-id-2>

# Restore a version
../kos checkout <snapshot-id>
cat readme.md  # Back to original

The Takeaway

Building KOS taught me that constraints aren't prison walls. They're focusing tools.

When I couldn't reach for go get, I had to understand my problems deeply. I had to learn about terminal I/O, writer layering, reference resolution, and encryption. I had to debug by understanding, not by reading someone else's code.

The result isn't just a tool. It's a tool I completely understand. It's a tool that's portable and secure. It's a tool that can run where nothing else can run.

That's worth the bugs. That's worth the deep dives. That's worth saying no to convenience.

Try KOS. Use it. Break it (please report issues). Learn from it.

And maybe, just maybe, build something with zero dependencies yourself. You'll be surprised what you learn when you can't go get your way out.

GitHub: kosmoscpp/kos

Quick Start:

git clone https://github.com/kosmoscpp/kos && cd kos && make install
kos init
kos save "My first snapshot"
kos view

That's it. No setup. No config. No dependencies. Just version control, zero friction.

Why GitWand is Rust, not Electron: what native performance actually buys a Git client

Fri, 21 Aug 2026 15:52:00 +0000

It's been a while since the last post here (v3.5, July 10). Since then, three releases have shipped: v3.6.0 (a handful of workflow polish items), v3.6.6 (a pure dev-loop and CI performance pass, no product surface), and v3.7.0 (Commit Review, a local AI pass over your staged changes). A straight changelog recap would cover all three, but it would miss the thing that actually connects them.

Every one of those releases is a direct consequence of a decision made on day one: build on Tauri 2 and Rust instead of Electron, and keep the actual conflict-resolution logic in a deliberately portable, zero-dependency TypeScript package instead of folding it into the Rust backend. That split sounds like an implementation detail. It isn't. It's the reason a 5-repo Launchpad refresh takes 30ms instead of most of a second, the reason a 30-second timeout bug fixed a few days ago (#166) had a one-line fix instead of a rewrite, and the reason the new Commit Review feature never has to touch a GitWand server. This post is about that decision, with real numbers pulled straight from the codebase instead of the usual "native is faster, trust us."

The bet, and who else made it

GitWand ships as roughly an 8 MB installed binary. GitKraken, built on Electron, ships in the ~150 MB class: a full bundled Chromium plus a full bundled Node.js runtime, running alongside each other, for an app that mostly renders text and spawns git. GitHub Desktop is the same story. The gap shows up at startup (GitWand is sub-1 second) and it shows up on large repos, where an Electron app's single JS heap has to hold and garbage-collect everything the UI touches.

To be fair to the field: GitWand isn't the only one making this bet anymore. GitButler is Tauri + Rust too. GitComet skips the webview entirely and goes pure Rust with GPUI. Strand is Tauri + React. Being native, in 2026, is closer to table stakes for a new Git client than a differentiator; RelaGit is the interesting counter-example, choosing Electron even with a SolidJS frontend for its fine-grained reactivity. The real question isn't "who avoided Electron," it's what each of these tools actually does with the native layer once it has it. That's the part worth walking through.

What Rust buys: fearless concurrency, with a number attached

Rust's ownership model turns a whole class of concurrency bugs into compile errors instead of production incidents. That's a nice sentence to put in a pitch deck. Here's what it looks like in a file that ships in the app today.

GitWand's multi-repo dashboard (Launchpad) needs the status of every repo in your workspace: branch, ahead/behind, modified-file count. The naive version spawns four git subprocesses per repo, one after another. GitWand's Rust backend does two things instead: each repo's status comes from a single in-process libgit2 call rather than four subprocess spawns, and every repo in the workspace gets processed in parallel via rayon's into_par_iter(), one core per repo instead of one core doing all of them in sequence. The comment sitting next to that code in the source states the measured result plainly: a 5-repo workspace listing went from about 750ms wall-clock to about 30ms in the typical case. That's not a marketing number, it's a comment next to a #[tauri::command] that ships today.

The same pattern shows up all over the backend, because once the tool exists, using it costs nothing extra: PR +/- stat enrichment across GitHub, GitLab, Azure DevOps, and Bitbucket all fan out per-PR diff computation across cores instead of looping; submodule status checks across a repo's submodules run in parallel; per-branch top-author lookups for the branch picker do too. A few days ago, a regression brought back a 30-second gh_list_prs timeout: the per-PR stats loop had gone back to running one git diff --numstat at a time. The fix wasn't a rewrite or a new thread pool, it was swapping a for loop for .par_iter_mut(). None of these needed hand-rolled synchronization or a bespoke worker pool. The parallel version and the serial version are the same number of lines, and if two of those parallel closures ever raced on the same mutable data, that's a compile error, not a bug report from a user with a corrupted status badge.

What Rust doesn't need to buy: the conflict engine stays TypeScript, on purpose

Here's the part a "Rust is fast" pitch usually skips: the actual pattern-classification engine, the code that decides same_change versus one_side_change versus complex and merges JSON, YAML, and lockfiles key by key, is not written in Rust. It lives in @gitwand/core, and that package is deliberately zero-Node, browser-safe TypeScript.

That's not a compromise, it's a second, equally deliberate architectural line. Classifying a few hundred lines of diff text against nine pattern rules finishes in single-digit milliseconds no matter what language it's written in; Rust's raw throughput wouldn't move that number in any way a user could feel. What Rust would have cost is portability: because the engine has no Node dependency, the exact same code runs inside the desktop app, in the CLI (npx @gitwand/cli resolve), inside the MCP server that AI agents call, and could run directly in a browser tomorrow with no changes. The rule GitWand actually follows isn't "everything is Rust." It's narrower and, we think, more useful: Rust owns the boundary with the operating system (spawning git, walking the filesystem, talking to forge APIs, the whole app shell), and the deterministic algorithmic core stays a small, dependency-light, portable package that isn't tied to any one runtime.

The unglamorous release: v3.6.6

v3.6.6 shipped no new product surface at all, just a dev-loop and CI performance pass, and it's the release that best shows the bet compounding on itself. Because the entire backend is one Rust crate, the same profiling discipline used to make the app fast also applies to making the build fast: a [profile.dev] tuned for lighter debug info cut a post-edit cargo build from about 21 seconds to about 6.5. On the CI side, a desktop job that produced three fully-signed release bundles on every single push to main, bundles nobody downloaded, was replaced with a fast rust-check job (fmt, clippy, check, test) that finally runs the app's 217 Rust unit tests in CI for the first time, saving roughly 230 billed CI minutes per push. On the TypeScript side, Vitest's global jsdom environment (needed by maybe a fifth of the test files, paid by all of them) was scoped down per-file, cutting environment setup time from about 96 seconds to about 17 across the suite.

Worth mentioning: before touching any of it, every claim in the plan for this work got re-measured against the actual codebase, not assumed. Several turned out to be wrong. "Any edit recompiles and relinks everything" wasn't true, cargo check after a real edit came back in under 2 seconds; the real cost was in the codegen-and-link step of a full cargo build. "The old jsdom setup costs 100 to 300ms per file" was an underestimate by roughly 10x once actually profiled. That's the same discipline the conflict engine's confidence scores are built on: don't ship a number you haven't checked.

Commit Review, and why local-first is the real differentiator

v3.7.0's headline feature, Commit Review, runs an AI pass over your staged changes right in the Changes panel before you commit, with inline findings and a "Fix with agent" action that hands them to a terminal AI session (Claude Code, opencode, or Codex) already running against your repo. What matters about it architecturally is what it doesn't do: it never calls a GitWand-run server. The review runs against whichever AI CLI you already have installed, on your machine, over your own already-open agent session.

That's the same "zero mandatory cloud" value the conflict engine already embodies, applied to review instead of merge. It's also the sharper contrast with where a chunk of the market is headed: tools positioning code-intelligence features as a metered cloud API (Greptile's own "Genius API" is priced at $0.45 per request) are betting that developers will pay per call for something GitWand ships as a local, free, opt-in feature built on tools you already run. Being local-first for conflict resolution and local-first for review isn't two separate decisions, it's the same one, applied twice.

The small stuff: v3.6.0

Between the two, v3.6.0 shipped things that don't need an architecture section to justify: a one-click "Update branch" prompt when you check out something behind its upstream, and a non-blocking handoff when an interactive rebase hits a conflict (issue #128), so the conflict editor no longer traps you behind a modal. These are the kind of small interactions that only feel good because there's no Electron process and no garbage-collector pause standing between the click and the result. The architecture doesn't just enable the big numbers, it's also why the boring stuff feels instant.

Where the bet goes next

The roadmap's next stop, v3.9.0 (Live Repo), applies the same philosophy one layer up: a Rust notify crate watcher replaces the current 2-second status poll with real filesystem events, more read paths move to in-process libgit2, and separately, the portable TypeScript core's diff/parse hot path gets moved off the main thread into a Web Worker. Same rule, two languages: Rust handles OS-level events natively and cheaply, and the portable core gets pushed off the render thread the way any JavaScript does it. One architecture, one non-negotiable: the UI thread never waits on either of them.

The market read

The Git GUI space is splitting into two camps: Electron incumbents charging a subscription for cloud AI features (GitKraken at $8/mo, with its advanced and AI features gated behind an account), and a newer wave of native, mostly free, often open-source tools built on Rust or a comparable native stack (GitButler, GitComet, Strand, and GitWand, with RelaGit staying on Electron by choice). Being native is fast becoming the price of entry for that second group, not what sets any one of them apart. What actually differentiates GitWand inside it is what the native layer gets used for: a conflict-resolution engine that classifies instead of guesses, multi-repo workflows that get genuinely (and measurably) faster because of how the backend is built, and an AI layer that never assumes your code should leave your machine.

Download GitWand for macOS, Linux, or Windows from GitHub Releases, read the full changelog, or see how the numbers stack up against specific tools on the compare pages.

Git & GitHub Basics Every Beginner Developer Should Know

Tue, 04 Aug 2026 05:00:00 +0000

Introduction

I avoided learning Git properly for way longer than I should have. I'd just zip my project folder and rename it project-final-v2-ACTUAL-FINAL whenever I wanted a backup. It worked, technically, until it very much didn't.

Git solves exactly this problem, and you genuinely only need about 10 commands to be productive with it. Here's everything you actually need, skipping the theory you won't use day-to-day.

Git vs GitHub — What's the Difference?

Git is the version control tool that runs on your computer. It tracks changes to your files over time.
GitHub is a website that hosts your Git projects online, so you can back them up, share them, and collaborate with others.

You can use Git without GitHub. You can't really use GitHub without understanding Git.

Setting Up (One-Time)

git config --global user.name "Your Name"
git config --global user.email "*Emails are not allowed*"

The Core Workflow

1. Initialize a repository

git init

Run this once, inside your project folder, to start tracking it with Git.

2. Check what's changed

git status

Shows you which files are modified, new, or staged. You'll run this constantly — it's your "what's going on right now" command.

3. Stage your changes

git add .

This stages all changed files, preparing them to be committed. Use git add filename.js to stage just one file.

4. Commit your changes

git commit -m "Add contact form component"

This saves a snapshot of your staged changes, with a message describing what you did. Write clear, specific messages — future you will thank present you.

Connecting to GitHub

5. Create a repository on GitHub

Go to github.com, click "New Repository," give it a name. Don't initialize it with a README if you already have a local project — you'll connect them next.

6. Link your local project to GitHub

git remote add origin https://github.com/yourusername/your-repo.git

7. Push your code

git push -u origin main

The -u flag remembers this connection, so future pushes just need git push.

Branches — Working Without Breaking Things

A branch lets you work on a new feature without touching your main, working code.

git checkout -b new-feature

Creates and switches to a new branch called new-feature.

git checkout main

Switches back to your main branch.

Once your feature works, merge it back:

git checkout main
git merge new-feature

Why this matters: if you're experimenting with something risky, do it on a branch. If it breaks, your main branch stays untouched and safe.

Pulling Changes

If you're working across multiple machines, or collaborating with others:

git pull

Downloads and merges the latest changes from GitHub into your local project.

Common Beginner Mistakes

Committing giant, vague changes. "fixed stuff" tells you nothing six months later. Commit small, logical chunks with clear messages.
Forgetting to pull before pushing when working with others — leads to avoidable merge conflicts.
Committing sensitive files like .env with API keys. Always set up a .gitignore file before your first commit.
Never using branches. Working directly on main for every experiment is how small mistakes become big headaches.

A Basic .gitignore for Frontend Projects

node_modules/
.env
dist/
.DS_Store

Save this as .gitignore in your project root before your first commit — it stops these files/folders from ever being tracked.

Final Thoughts

You don't need to memorize every Git command that exists. status, add, commit, push, pull, and basic branching cover probably 90% of real, everyday use. Learn these solidly, and the rest you can look up as you go.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

Git Worktrees Are Underrated

Sat, 18 Jul 2026 22:31:32 +0000

If you've ever stashed half-finished work to review a PR, or lost a train of thought switching branches, you should know about git worktrees. They've been in git since 2015, but most developers I talk to have never heard of them.

The problem with branches

The standard git workflow is linear. You're on a branch, you need to context-switch, so you stash your changes (or worse, make a throwaway commit), switch branches, do your thing, switch back, and pop the stash. If you're lucky, nothing conflicts.

This gets worse when you're juggling multiple things at once. Reviewing a colleague's PR while your feature branch is mid-refactor. Running tests on one branch while coding on another. Hotfixing production while your main work sits frozen.

A git repository has one working directory. One branch checked out at a time. Everything else has to wait.

Worktrees

Git worktrees let you check out multiple branches simultaneously, each in its own directory. They share the same .git history and objects, so you're not cloning the entire repo, but each one has its own working directory and index.

git worktree add ../feat-login feat/login

Now feat/login is checked out in ../feat-login. You can open it in a separate editor window, run tests there, or just let it sit while you work on something else.

When you're done:

git worktree remove ../feat-login

Why nobody uses them

If worktrees are so useful, why aren't they more popular? I think it comes down to two things.

First, the directory problem. Every time you create a worktree, you have to pick a path. There's no convention for where they go. After a week you end up with directories scattered across your filesystem: ../feat-login, ~/tmp/hotfix-auth, ../../pr-review. Good luck remembering where anything is.

Second, there are no ergonomics. You can't easily list your worktrees with status info, cd into one quickly, or run something like npm install in the new directory after checkout. The raw git commands work, but they don't make worktrees feel like a real workflow.

These aren't fundamental problems with worktrees. They're tooling gaps. That's why I built arbor.

A better workflow with arbor

Arbor is a CLI that manages git worktrees. It keeps them organized in a central directory (~/.arbor/worktrees/) and handles the stuff that plain git doesn't.

# Clone a repo (sets up a bare repo + default branch worktree)
arbor clone user/my-app

# Create a worktree for a new feature
arbor add feat/login

# Shell integration auto-cds you into the worktree
# You're now in ~/.arbor/worktrees/my-app/feat-login

# Need to review a PR? Open another worktree
arbor add fix/auth-bug

# See all your worktrees with dirty/clean status
arbor ls

Every worktree for my-app lives under ~/.arbor/worktrees/my-app/. Branch slashes become dashes in directory names, so the filesystem stays tidy. When you're done with a branch:

arbor rm -d feat/login

That removes the worktree and the local branch in one step.

What makes it stick

I've been using worktrees for a while, but I kept falling off because of the friction. A few things in arbor made the difference for me.

Shell integration. arbor init sets up a wrapper so that arbor add and arbor switch automatically cd you into the worktree directory. Without it you create the worktree and then have to cd into it yourself every single time, which gets old fast.

Post-create hooks. You can add an .arbor.toml to your repo:

[hooks]
post_create = "npm install"

Every new worktree gets its dependencies installed automatically. You can chain commands too:

[hooks]
post_create = ["npm install", "cp .env.example .env"]

And arbor ls --all shows the state of every worktree across all your repos, which is nice for a quick scan before you call it a day.

Where I use them most

PR reviews. arbor add the branch, review it in a separate editor window, remove it when done. My own work is untouched.

Long test suites. Tests running on one branch, coding on another. No waiting around.

Hotfixes. arbor add hotfix/critical, fix it, push it, remove it. Back to what I was doing.

Comparing behavior. Two worktrees open side by side, one on main and one on my feature branch. Way easier than switching back and forth.

Big migrations. Upgrading a framework to a new major version in a worktree while the rest of the team keeps shipping from main, the way I kicked the tires on SolidJS 2.0 and dug into its async data model. No half-broken build blocking anyone.

Git worktree best practices

A few habits keep worktrees from turning into the mess that makes people give up on them, whether you're on arbor or raw git.

Keep them in one predictable place. Pick a home for your worktrees and stick to it: a ~/worktrees/ directory, or let arbor manage ~/.arbor/worktrees/ for you. Scattering them across ../, ~/tmp, and ../../ is how you lose track of what lives where.

One branch per worktree. Git won't let you check out the same branch in two worktrees without --force, and that guardrail is worth respecting. Keep the mapping one branch to one directory.

Create the branch and the worktree together. git worktree add -b feat/login ../feat-login makes the branch and checks it out in the new directory in a single command, instead of creating the branch first and adding it after.

Remove worktrees with git, not rm -rf. Run git worktree remove ../feat-login instead of deleting the directory by hand. A manual delete leaves stale metadata behind in .git/worktrees, which you then have to clear out with git worktree prune.

Run git worktree list when you lose the thread. It prints every worktree with its branch and commit, so you can see what's checked out where before you go hunting through directories.

Don't nest them. Give each worktree its own top-level directory rather than tucking one inside another worktree or the main repo. Nesting confuses tooling, and worktrees on a repo with submodules are only partly supported anyway.

Try it

Arbor is open source, written in Rust. Install with Homebrew:

brew install morellodev/tap/arbor

Or grab a binary from the releases page.

Run arbor init after installing to set up shell integration. Takes about 30 seconds.

If you've never tried worktrees, give them a shot. And if you have but gave up because of the directory mess, this might be worth another look.

The repo is at github.com/morellodev/arbor.

Git Branch Pinning and Auto-Archiving: What's New in Tower 13 for Windows

Wed, 15 Jul 2026 17:21:47 +0000

Every long-running repo ends up with the same problem: a branch list full of stuff that's already merged or long abandoned, with the branches you actually need buried somewhere in the middle.

Tower 13 for Windows adds two features built specifically to deal with that — Branch Pinning and Automatic Branch Management. Both have existed on Tower for Mac for a while (Pinning since Tower 8, Auto Branch Management since Tower 15) and are now available on Windows.

Branch Pinning

Right-click a branch to pin it, and it moves into a dedicated "Pinned" section at the top of the sidebar. You can pin or unpin several branches in one go, pinned branches are automatically protected from auto-archiving, and pins are stored in your Git config so they persist reliably.

Fully Merged and Stale badges

New badges flag branches as Fully Merged (every commit integrated into the parent, and the tracked remote branch already deleted) or Stale (no recent activity). Selecting a flagged branch brings up a hint view with a one-click delete option, so you can confirm cleanup without digging through menus.

Automatic Branch Management

A new "Archived Branches" view holds branches you've set aside — added manually via drag-and-drop or the context menu, or moved there automatically based on a stale interval you configure in settings. Clicking the notification counter in the footer opens a dialog to review and approve archiving in bulk before anything happens. Archived branches can be unarchived at any time, and any branch can be flagged "Skips Auto-Archiving" if you want to protect it without formally pinning it.

Other changes in this release

Untracked files now show their contents directly in the diff view, the Windows build has been updated to run on .NET 10, and there are various fixes across the diff view, submodule handling, and multi-branch/tag operations.

Full details: Tower 13 for Windows release notes.

Git Will Humble You (And That's Okay)

Wed, 15 Jul 2026 05:28:26 +0000

Hey fam

This is my first ever dev article, and yes - I'm nervous.

So real talk — nobody warned me that learning to code would sometimes feel like arguing with a robot that's always right and never explains why you're wrong.

That robot? Git.

If you're a first-time developer, you've probably already had that moment. You type some command with full confidence, hit enter, and then... chaos. Your files are gone. Or duplicated. Or you're somehow on a branch that doesn't exist. Or the classic — you pushed to main when you absolutely should not have.

We've all been there. This post is for you.

What Even IS Git?

Git is a version control system — basically a time machine for your code. It tracks every change you make, lets you collaborate with other developers, and (in theory) saves you from destroying your own project.

The key word there is in theory.

The Commands That Will Ruin Your Day (If You're Not Careful)

git push --force

Oh, this one. This is the "delete everything and ask questions never" command. If you force push to a shared branch without knowing what you're doing, your teammates will find you. Don't do it until you really understand what it does.

git reset --hard

Hard reset sounds powerful because it is. It throws away all your uncommitted changes — no warning, no undo. Ran it once thinking it would fix my mess. It made a bigger mess.

git merge vs git rebase

These two will have you in a full philosophy debate at 2am. Both combine branches. Both will cause merge conflicts that look like ancient hieroglyphics. Learn the difference early — your future self will thank you.

Committing with no message (or a terrible one)

git commit -m "fix" — said every developer who regretted it 3 weeks later. Be descriptive. Always.

Why Mastering Git Early Actually Matters

When you're just starting out, it's easy to think Git is just a way to upload your code to GitHub or Gitea and look productive. But here's the thing — Git is your safety net. The better you understand it:

The less likely you are to lose work
The easier it is to collaborate without chaos
The more confident you look in team settings (yes, employers notice)
The faster you can recover when things break — and they will break

Git isn't just a tool. It's a habit. Build it early.

Resources to Actually Get Good

Here are some solid places to level up your Git, Go, Shell, and Rust game:

Git:

Pro Git Book — free, thorough, the bible
Oh My Git! — learn Git through a game (yes, really)
Learn Git Branching — visual and interactive

Go (Golang):

Go by Example — clean, no fluff

Shell / Bash:

The Linux Command Line by William Shotts — free online

Rust:

The Rust Book — the official one and it's actually great

Now I Wanna Hear From YOU

Drop it in the comments:

What was your first Git disaster?
What's the command that made you question your life choices?
Are you learning Go, Shell, or Rust right now? How's it going?

Let's laugh about it together — because if you're not breaking things, you're not learning.

If this helped you even a little, hit that ❤️, drop a comment, and let's connect!

Find me on LinkedIn → Mayan Okul — @mayan Okul — come say hi, seriously.

Tags: #git #golang #shell #rust #Zone01 #codenewbie #devjourney #programming #firstpost

"Push code, not limits — unless it's a feature branch. Then push everything."
— stay debugging, stay dangerous ⚡

— Mayan, your fav/baddest developer__

The Hidden Engineering Behind Git Merge Conflicts

Mon, 13 Jul 2026 12:12:16 +0000

If you've worked with Git for even a few weeks, you've probably seen this message:

CONFLICT (content): Merge conflict
Automatic merge failed.

Your heart sinks.

You stare at the screen and think:

👉 "What did I do wrong?"

The truth is...

Most merge conflicts aren't caused by bad developers.

They're simply a side effect of multiple people working on the same codebase.

Let's see what's actually happening behind the scenes.

💡 Git Doesn't Understand Your Code

Here's something many developers don't realize.

Git doesn't understand:

JavaScript
Java
Python
React
Node.js

Git simply sees...

👉 Text files.

It doesn't know what a function is or what a variable means.

It only knows:

"This line changed."

👨💻 A Simple Example

Imagine your login.js file contains:

function login() {
   return true;
}

Now two developers start working.

Developer A

Changes it to:

return false;

Meanwhile...

Developer B

Changes it to:

return validateUser();

Both changes happen on different branches.

🤔 Now Git Gets Confused

When the branches are merged...

Git asks itself:

"I have two different changes for the same line."

Which one should I keep?

Developer A's?

Or Developer B's?

Git has no idea.

So instead of guessing...

It stops.

And asks you to decide.

That's a merge conflict.

🚀 Why Git Doesn't Auto-Fix Everything

People often ask:

"Why can't Git just combine both changes?"

Because sometimes there isn't a correct answer.

Imagine:

One developer deletes a function.

Another developer adds new logic inside that same function.

Should Git:

Keep the deletion?
Keep the new logic?
Combine both?

Only the developer understands the intent.

Git doesn't.

⚙️ What Those Weird Markers Mean

When a conflict happens, you'll see something like:

<<<<<<< HEAD
Developer A's code
=======
Developer B's code
>>>>>>> feature-branch

Git is simply saying:

"Here are both versions.
You choose the correct one."

After editing the file and removing these markers, the conflict is resolved.

🤝 Why Merge Conflicts Increase in Large Teams

In small projects...

Conflicts are rare.

In large projects:

Multiple developers
Multiple features
Long-lived branches
Frequent releases

The chances of two people modifying the same file become much higher.

That's why enterprise teams often merge changes frequently instead of waiting for weeks.

💡 How Good Teams Reduce Merge Conflicts

Experienced teams don't eliminate conflicts completely.

Instead, they reduce them by:

Creating smaller pull requests
Merging branches frequently
Keeping branches short-lived
Improving communication
Breaking large features into smaller tasks

The goal isn't "no conflicts."

The goal is "easy conflicts."

🎯 The Bigger Lesson

A merge conflict isn't Git being broken.

It's Git protecting your work.

Instead of making the wrong decision...

Git lets the developer make the final call.

That's actually a safety feature.

🚀 Final Thought

The next time Git says:

"Automatic merge failed."

Don't panic.

It's not telling you that your project is broken.

It's simply saying:

👉 "Two smart developers made different changes. I need your help deciding which one is correct."

And that's the hidden engineering behind one of the most common messages every developer eventually learns to respect.

💬 What's the longest merge conflict you've ever had to resolve? 😄

Git #GitHub #SoftwareEngineering #Developers #Programming #VersionControl #Coding #WebDevelopment #DeveloperLife

Continuous Delivery Office Hours Ep.3: Branching strategies

Mon, 13 Jul 2026 11:13:02 +0000

Your branching strategy can support Continuous Delivery, or make it an impossible goal. You should assess the impact of how you branch on your ability to deliver software at all times, and you'll find some branching techniques that work, while others that make software delivery more like walking in the dark through a field of rakes.

Continuous Integration is the practice of integrating code changes frequently, typically multiple times a day. This means you should check your code multiple times a day and keep your main branch deployable. Continuous Integration is a prerequisite for Continuous Delivery.

The name "Continuous Integration" provides solid hints about the crucial parts of the practice. Everyone should integrate their code into a shared branch (feature branches don't count) and this should be done continuously, which means you're doing it all the time; at least once a day, but ideally more often.

You'll often speak to developers who want to stretch the definition of Continuous Integration, but you can't escape those foundations. Merging the main branch into a long-lived branch feels like Continuous Integration, but you'll notice no changes come back for ages until someone finally merges to main. Then you have to perform a large, complex merge, which you should avoid.

The DORA research on Continuous Delivery includes the capabilities of Continuous Integration and trunk-based development. The statistics suggest you can get similar benefits as long as you limit yourself to 3 (or fewer) short-lived branches (less than a day old).

Watch the episode

You can watch the episode below, or read on to find some of the key discussion points.

Watch Continuous Delivery Office Hours Ep.3

The worst branching strategy

Since the ability to branch code was invented, developers have applied a great deal of creativity to how to use branches. The most common approach is feature branching, where each feature gets a branch of main that evolves separately until the feature is complete, and it's merged back into main. Release branching allows development to continue on main by taking a cut of the main branch that will be released. This allows hotfixes to be applied to the release branch without further destabilizing it.

The utility of branching strategies is often eroded by the coordination overhead of maintaining the separate branches and merging different changes back together. The more complex the branching strategy, the more likely it is that you'll have merge conflicts and lost bug fixes. For example, you might fix a release branch and forget to merge the fix back to main, so the next release reintroduces the bug.

This is why the worst branching strategy is Gitflow. This is a complicated branching strategy that creates dedicated branches for features, releases, and hotfixes alongside permanent main and develop branches. The overhead of Gitflow vastly outweighs its benefits.

This is where trunk-based development shines, as it removes unnecessary complexity.

The best strategy is trunk-based development

Trunk-based development is the process of making all commits directly to the main branch. This is complemented by out-of-band reviews that don't block merging and by feature toggles that decouple deployments from releases. It should be possible to deploy your software from the main branch at all times, even if features aren't complete.

The DORA research allows up to 3 short-lived branches, which can be useful for teams working remotely (like open-source project teams), who can use branches and pull requests to coordinate their work. Even so, the goal is to keep branches short-lived and to merge frequently.

Trunk-based development is complemented by automated builds and checks that run when code is committed to the main branch. If a problem is found during these checks, the team should prioritize the fix over other development work.

Elite performance comes from small batches

Teams with the best software delivery performance work in small steps. Trunk-based development and Continuous Integration are crucial practices for controlling batch size. Problems are discovered sooner and are easier to fix when you only have a small amount of change to reason about.

Making frequent commits makes it easy to back out a bad change. If a test fails, you can discard changes since the last commit and try again, instead of trying to debug the problem. This is especially true when using AI coding assistants or other code generation techniques.

Ultimately, for trunk-based development to succeed without friction, the entire team must be aligned on the process. It doesn't work if only some of the team are on board.

Continuous Delivery Office Hours is a series of conversations about software delivery, with Tony Kelly, Bob Walker, and Steve Fenton.

You can find more episodes on YouTube, Apple Podcasts, and Pocket Casts.

Codicology for Compiled Code: Triangulating Authorship When Git Blame Lies

Sun, 05 Jul 2026 01:30:37 +0000

Originally published on Vibe Agent Making.

Triangulating authorship when git blame lies — what medieval manuscript authentication teaches software forensics about the evidence nobody designed.

Open a thirteenth-century parchment codex to any two-page spread and look at the surface, not the text. On the left page, tiny follicle marks where hair once grew — a faint roughness, a slightly yellowed cast. On the right page, the same. Flip forward: smooth, cream-colored flesh side faces flesh side. This alternation — hair to hair, flesh to flesh — runs through the entire book with the regularity of a heartbeat.

No medieval scribe thought of this as a security feature. They were making a beautiful book. Hair side is rougher and darker than flesh side; alternating them within a spread would look jarring, so bookmakers arranged their parchment sheets to keep each opening visually consistent. Caspar René Gregory, an American textual scholar working in nineteenth-century Germany on New Testament manuscripts, was the first to formalize what this incidental regularity meant for authentication. When a leaf has been inserted into a quire — a forgery, a later interpolation, a replacement — the hair-flesh alternation breaks. A checksum failure, centuries before checksums.

Gregory’s Rule, as codicologists now call it, illustrates a principle that software forensics has been slow to learn: the most diagnostic evidence of tampering is often the evidence nobody designed.

The paleographic playbook

Manuscript scholars never trust a single dating indicator. The standard method — described in paleography handbooks from Bernhard Bischoff’s Latin Palaeography (Cambridge UP, 1990) onward — triangulates across multiple independent evidence types.

Script. A trained paleographer dates Latin manuscripts to within a quarter-century by letterform alone, for most of the period after 800 CE. The angle of the pen, the proportions of ascenders and descenders, the treatment of ligatures — these are as individual as handwriting, because they are handwriting.

Watermark. For paper codices, Charles-Moïse Briquet’s Les Filigranes (1907) catalogued European paper-mill watermarks so thoroughly that matching one narrows the date to a five-to-twenty-year window and a particular mill’s region.

Ruling pattern. Before writing, scribes ruled lines into the parchment with a stylus, lead, or ink. The spacing, the number of columns, the margin conventions — these are datable independent of the script and by different specialists.

Quire construction. A quire is a gathering of folded parchment sheets sewn together. Quire boundaries often show changes of ink, hand, or layout. An inserted leaf whose ruling doesn’t match its quire is diagnostic.

Parchment preparation. Regional and period-specific. Coarse versus fine, thick versus thin — the substrate itself carries temporal and geographic signal.

Ownership marks. The first recorded owner gives a terminus ante quem: the book must have existed before that person could sign it.

No one of these is conclusive. A responsible manuscript catalog entry hedges deliberately: “s. xii², perhaps third quarter, northern France (Champagne?), probably Cistercian provenance.” That phrasing reflects the underlying evidence, not the cataloguer’s timidity. It is the most honest thing anyone has said about dating in any discipline.

When git blame lies

Now consider how software development handles the equivalent question — who wrote this code, and when?

Almost exclusively, the answer is git blame. One command, one indicator: the commit that last modified each line. And for most purposes, it works. But a paleographer looking at this arrangement would wince. git blame is ownership marks with no supporting evidence — the medieval equivalent of trusting a colophon and nothing else.

The fragility is well-documented. git rebase and git filter-branch can rewrite entire commit histories — the software equivalent of a scribe erasing and rewriting a colophon. A single prettier or black run reassigns every line to the formatter’s commit, erasing the attribution trail as thoroughly as a later scribe rebinding and reruling a codex. Squash merges collapse multiple authors’ work into a single commit — a patron recorded as “author” of a compilation manuscript. And now, AI assistance: code generated by Copilot or Claude Code is committed under the human’s name, the human’s hand pushing someone else’s text.

The stylometric research bears this out. On single-author, whole-file attribution, code authorship methods achieve accuracy above 90% (Caliskan-Islam et al.; Kalgutkar et al., ACM Computing Surveys 52(1)). But on collaborative code segments — the kind git blame actually deals with — Dauber and Caliskan found accuracy drops to 50–60% (“Git Blame Who?,” arXiv:1701.05681, 2017). And adversarial edits defeat current attribution methods with unsettling regularity. As a 2024 survey in MDPI Information put it: “As of now, there is no code authorship attribution method capable of effectively handling such attacks.”

One indicator. Easily faked. Easily broken by routine operations. This is the problem.

The fingerprints you didn’t know you were leaving

Here’s where it gets interesting. Two studies from 2026 have mapped the fingerprinting landscape for AI-generated code, and the findings would delight a paleographer.

The first — “Fingerprinting AI Coding Agents on GitHub” (arXiv:2601.17406) — analyzed 33,580 pull requests across five AI coding agents: OpenAI Codex, GitHub Copilot, Devin, Cursor, and Claude Code. An XGBoost classifier achieved 97.2% F1-score in identifying which agent produced the code. But the counterintuitive finding was where the fingerprints live: commit message conventions were more discriminative than the code itself. The multiline commit ratio alone carried 44.7% of the discriminative power. Each agent had its own metadata signature — OpenAI Codex wrote verbose multiline commits, Cursor peppered PR bodies with bullet points and hyperlinks, Claude Code showed high conditional density and elevated comment rates.

A paleographer would nod. Colophons — scribal subscriptions at the end of manuscripts — often reveal more about authorship than the text itself. The scribe’s personal formula, their dating convention, their invocation: these are the metadata of the medieval book, and they fingerprint the maker more reliably than the content does.

The second study — “Code Fingerprints: Disentangled Attribution” (DCAN, arXiv:2603.04212, March 2026) — found something equally striking: attribution accuracy improves with task complexity. Easy tasks produce canonical solutions that look the same regardless of who or what wrote them. Hard tasks amplify stylistic variation. The paleographic parallel is exact: standard Caroline minuscule — the workhorse book script of Carolingian Europe — is notoriously difficult to attribute to a specific scriptorium, precisely because it was designed for uniformity. But an idiosyncratic display script, a scribe’s vernacular hand, an experimental ligature — those localize immediately. The mundane is the hardest to fingerprint, in any medium.

And perhaps most remarkably, DCAN found that LLM fingerprints persist across programming languages — 93.48% cross-language attribution accuracy with comments included. Claude writes identifiably like Claude in Python, Java, Go, and C, just as a medieval scribe’s hand is recognizable whether they’re copying Latin or vernacular French. The authorial identity runs deeper than the surface language.

The translation

What manuscript studies offer software forensics is not a metaphor. It’s a methodology.

Script analysis → Code stylometry. Token frequencies, abstract syntax tree shapes, naming conventions, indentation patterns — these are the ductus of code, the pen-angle and stroke-order that identify the hand.

Watermark dating → Build-tool-chain fingerprints. Compiler flags, bundler versions, lockfile formats — the toolchain leaves marks as specific as a paper mill’s wire pattern.

Ruling pattern → Formatting configuration. .editorconfig, .prettierrc, linter rules — the invisible grid that structures the page.

Gregory’s Rule → Substrate invariants. Line-ending consistency (CRLF versus LF), encoding (UTF-8 BOM presence), whitespace regularity, entropy patterns. Nobody designs these as authentication mechanisms. They function as checksums anyway. AI-generated code insertions break them because the generating model doesn’t preserve the repository’s incidental regularities — just as a forger focused on imitating a script might not think to match the parchment orientation.

Parchment preparation → Dependency fingerprints. Package ecosystem, version pinning patterns, registry choices. The supply-chain provenance of a codebase’s dependencies is as regional and temporal as the preparation of a calfskin leaf.

Ownership marks → Git metadata. Author email, timezone, GPG signatures. And as easily forged as an ex-libris plate glued into a stolen book.

The through-line is the paleographic maxim: every single indicator can be faked in isolation, but faking all of them simultaneously is exponentially harder. A manuscript forger can imitate a twelfth-century script, but matching the script plus the correct watermark for the region plus period-appropriate ruling plus proper quire construction plus consistent ink chemistry requires expertise across five distinct subspecialties. A git history rewriter can fake commits, but simultaneously preserving consistent stylometric patterns, matching build-tool artifacts, maintaining timezone coherence, and keeping dependency version patterns plausible requires awareness of forensic techniques that most rewriters don’t anticipate.

And here’s the argument’s sharpest edge: digital substrates need more triangulation than physical ones, not less. Parchment has an inherent audit trail — you can’t un-scrape a surface, un-bond iron-gall ink from the fibers, un-disturb the collagen structure. Code has no such substrate memory. Every bit is perfectly copyable, every history perfectly rewritable. The more amnesiac the substrate, the more independent indicators you need.

Where the analogy breaks

Three ways, ordered by severity.

First: physical irreversibility has no digital equivalent. A paleographer examining a palimpsest — a scraped-and-rewritten parchment — can recover the original text through multispectral imaging because the ink chemically bonded with the collagen. A rewritten git history leaves no such trace. The reflog helps for a while, but it’s local, temporary, and trivially deletable. The substrate’s amnesia is fundamental, not incidental.

Second: the adversarial gap. Current code attribution methods fold under targeted adversarial attacks at rates that have no paleographic equivalent. You cannot automate the production of convincing medieval parchment, period-appropriate iron-gall ink, and a twelfth-century hand. Adversarial stylometric evasion, on the other hand, is a script away. The attacker’s cost is categorically different in the two domains.

Third: scale and velocity. The largest medieval library held thousands of codices. A modern enterprise codebase has millions of files, thousands of contributors, and continuous automated modifications. Any triangulation framework for code must operate at a scale that would make autoptic examination — Gregory’s careful, physical handling of each codex — impossible. The method must be automated, or it will remain an academic exercise.

These are real limits. They mean the translation cannot be literal. But they don’t invalidate the methodology — they intensify the need for it. The paleographic playbook was developed precisely because no single indicator was trustworthy. Software forensics faces the same problem with weaker substrate guarantees, and yet it mostly still relies on the equivalent of reading the colophon and calling it a day.

The incidental invariant

Gregory wasn’t looking for a security mechanism. He was a textual scholar trying to understand how New Testament manuscripts were physically constructed. The hair-flesh alternation pattern he documented was a byproduct of bookmaking aesthetics, not a designed authentication feature. Its forensic power was discovered, not invented.

Every codebase is full of the same kind of unconscious regularity. The way one team consistently names error variables. The timezone pattern in commit metadata. The specific version of a lockfile format that pins the code to an era of toolchain development. The entropy signature that distinguishes handwritten logic from generated boilerplate.

None of these were designed as forensic indicators. None of them need to be. The question is whether, eight hundred years into the tradition of making sense of other people’s texts, we’ll have learned to read what was there all along — or whether we’ll still be trusting the colophon.

Sources

Dauber & Caliskan, “Git Blame Who?” (arXiv:1701.05681, 2017)
“Fingerprinting AI Coding Agents on GitHub” (arXiv:2601.17406, 2026)
“Code Fingerprints: DCAN” (arXiv:2603.04212, March 2026)
“Authorship Attribution Methods, Challenges, and Future Research Directions” (MDPI Information 15(3), 2024)
Kennedys Law, “86% fake — 100% admissible?” (2026)
Gregory’s Rule — Goucher College faculty resource (faculty.goucher.edu)
Bischoff, B., Latin Palaeography: Antiquity and the Middle Ages (Cambridge UP, 1990)
Briquet, C. M., Les Filigranes (1907)

The evidence nobody designed is the evidence that matters. No single indicator — git blame, a commit message, an author field — survives scrutiny alone. You need triangulation across independent evidence types, where faking all of them simultaneously is exponentially harder than faking any one. That is the codicologist’s lesson for software forensics.

The real risk was not the code I could see. It was the code Git could run for me.

Wed, 01 Jul 2026 17:06:54 +0000

The malware was not in the app. It was in .git/hooks.

My first job hunt taught me to inspect the repo before trusting the task

I am currently looking for my first job So when a recruiter messaged me on LinkedIn and sent over a take-home repository, I treated it seriously. This was one of the first real task-based opportunities I had received, so I wanted to do everything properly.

I reviewed a take-home repository that came through recruiter outreach.

It was a web3 front end with WalletConnect, Transak, Uniswap widgets, Infura, Etherscan, and configuration driven REACT_APP_* env vars. The kind of stack you would expect from a real production app. That was exactly why I almost missed the part that mattered. Before running anything, I started checking the repo structure, package scripts, and Git metadata. I did not run install commands. I did not start the app. I did not assume the repository was safe just because it came through a recruiter.

At first glance, it looked normal enough for a production web3 front end. WalletConnect. Transak. Uniswap widgets. Infura. Etherscan. Vercel Analytics. Env-driven config for chain IDs, contract addresses, fees, and backend URLs.

That part did not bother me.

The red flag was lower level.

Inside the repo-local .git/hooks directory, I found executable pre-commit, pre-push, and post-checkout scripts. They did not validate code. They did not format files. They did not run tests.

They fetched remote content from a hardcoded IP address and piped it into a shell or command interpreter.

That is not a build step.

Actual Screenshot of post-checkout, pre-commit, pre-push file

That is a downloader.

Git hooks matter because Git runs them automatically on specific events. pre-commit runs before commits. pre-push runs before pushes. post-checkout runs after a checkout. Git also allows

hooks to live in .git/hooks or in a configured core.hooksPath, and git init can copy hook templates into a repo.

So if a malicious hook sits in the repo, the attack surface is not just the app. It is the developer workflow.

That is the part people miss.

The workflow pattern Here is the basic flow I observed:

The candidate is approached like a normal hire The conversation starts like a standard recruiter or hiring process. The task is framed as a practical engineering evaluation, not a public challenge.

https://docs.google.com/document/d/1UTEmB8WRIEP1XQb9R2kVhCNLPkqxBo37WhS2unfhYJQ/edit?usp=sharing

This lowers suspicion because it feels like a legitimate private assessment.

The Person or Profile that blocks me after I confirmed it;https://www.linkedin.com/in/paula-andrea-díaz-loaiza-481ba9232/

The time I get blocked or they delete?

2. The project is shared as a zip file Instead of a clean private GitHub repository, the project is delivered as a Dropbox package.

https://www.dropbox.com/scl/fi/3bb255hoju2sxh9k7ml2h/datalake-token-app.zip?dl=0&e=2&file_subpath=%2Fdatalake-token-app&rlkey=jpk7vaw2n8kqrbzk8u3e8otcj&st=cmh3zbzg

That matters because:

it removes the normal protections and visibility of a repo,

it makes the workflow feel “local and manual,”

and it encourages the candidate to unpack and inspect the code on their own machine.

The codebase looks real The project itself is not empty or fake-looking. It contains a real frontend app, real Web3 integrations, real environment-driven configuration, and even sensitive-looking .env material.

That is important because a believable app builds trust.

1. The assignment asks for Git-based work The candidate is told to:

create a new branch,add a review file,push the project, and return the GitHub URL.

This is where the workflow becomes interesting.

It makes the candidate behave like a normal developer:

clone or unpack,inspect,branch,commit,push.

That is exactly the behavior malicious hooks are waiting for.

2. Malicious hook files sit in .git/hooks Hidden in the repo are hook files like:

pre-commit,pre-push,post-checkout.

Minimize image Edit image Delete image

Add a caption (optional) These are not ordinary project files. They are execution points Git can trigger automatically.

The scripts I found were not harmless automation. They used a pattern like:

detect the OS, fetch a remote payload from an IP address,pipe it directly into sh or cmd,hide output, and run in the background.

Minimize image Edit image Delete image

Add a caption (optional) That is a classic downloader-style execution chain.

The payload is triggered by normal Git actions The dangerous part is not just that the scripts exist. It is that they can fire during ordinary Git operations:

commit,push,checkout.

So the candidate does not need to do anything unusual.

A normal workflow action can become the trigger.

Why this scheme works This workflow is effective because it mixes trust and routine.

It succeeds when:

the task looks professional,the app looks real, the instructions sound standard,

and the candidate follows normal Git behavior without checking hook files first.

The candidate thinks they are doing an interview task. In reality, they may be executing a hidden payload.

What makes it dangerous The risk is not just “bad code.”

The actual danger is the combination of:

social engineering, believable delivery, hidden Git execution points, and remote code download.

That means the workflow itself is the attack.

They inspect src/, package.json, and the dependencies. They forget that Git metadata can execute code before the app ever starts.

I did not treat this lightly. I checked the package scripts first. I did not run install commands, startup commands, or any Git action that could trigger hooks. The application itself did not show obvious preinstall or postinstall trickery. The dangerous behavior lived in the Git layer. That distinction matters.

What made this worse is that Git hooks are not decorative files. Git runs them automatically at specific events. A developer can trigger them just by committing, pushing, or checking out code. So if a malicious hook is sitting inside the repo, it does not matter that the app code looks clean. The attack path is already in place.

This was the first time I had to think about a job task in two layers at once.

The visible layer was the app.

The hidden layer was the repository itself.

And that changed how I now review any take-home assignment. I no longer start by asking, “Does the app work?” I start by asking, “What executes before the app even opens?”

This repo contained hook-based remote code execution behavior. And that pattern is not hypothetical. Security writeups have documented Git-hook abuse in fake interview and recruiter-style campaigns, especially where the target is a developer working in crypto or web3. Detection content from security vendors also treats Git-hook execution and hook-origin network egress as suspicious.

So the practical lesson is not "never trust web3 projects."

The lesson is "never trust a repo until you inspect the parts outside the app."

If you receive an interview task or a code sample from a stranger, check these before you run anything:

.git/hooks
.git/config
core.hooksPath
package.json scripts
lockfile install scripts
any shell, PowerShell, or Python files that run during setup

If a hook reaches out to the network and executes what it gets back, stop there. That is not a hook anymore. It is a launcher.

I now treat interview repos as hostile until proven otherwise.

Not every repo with hooks is malicious. Normal hooks exist. But normal hooks do not phone home and execute remote payloads.

That is the line.

I am publishing this because the defensive habit matters more than the story itself. Read the metadata. Check the hooks. Do not assume the dangerous code will be in src/.

If you review take-home repos, have you ever looked past the app code and found something in Git metadata?

Sources I checked included Git's hook documentation, recent threat-intel reporting on Git-hook abuse, and vendor detection guidance for hook-based persistence and egress.

Core incident pattern SocPrime — Git hooks used to hide malware in fake interview workflows: https://socprime.com/active-threats/lazarus-group-uses-git-hooks-to-hide-malware-dprks-contagious-interview-and-taskjacker-campaigns/socprime

OpenSourceMalware — Lazarus / Contagious Interview using Git hooks: https://opensourcemalware.com/blog/lazarus-group-uses-git-hooks-to-hide-malwareopensourcemalware

Andrii.ro — Investigating malware spreading through Git repositories: https://andrii.ro/blog/investigating-malwareandrii

Microsoft Security Blog — Contagious Interview fake developer job malware: https://www.microsoft.com/en-us/security/blog/2026/03/11/contagious-interview-malware-delivered-through-fake-developer-job-interviews/microsoft

Detection and security references Elastic detection rule — Git Hook Command Execution: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/linux/persistence\_git\_hook\_executionelastic

Elastic / Detection FYI — Git Hook Egress Network Connection: https://detection.fyi/elastic/detection-rules/linux/persistence\_git\_hook\_netcon/detection

Elastic hunting query repo reference: https://github.com/elastic/detection-rules/blob/main/hunting/linux/queries/persistence\_via\_git\_hook\_pager.tomlgithub

SonarSource — Securing developer tools / Git integrations: https://www.sonarsource.com/blog/securing-developer-tools-git-integrations/sonarsource

Fake recruiter / fake interview campaign coverage BleepingComputer — Fake job recruiters hide malware in developer coding challenges: https://www.bleepingcomputer.com/news/security/fake-job-recruiters-hide-malware-in-developer-coding-challenges/bleepingcomputer

BleepingComputer — New wave of fake interviews use npm packages to spread malware: https://www.bleepingcomputer.com/news/security/new-wave-of-fake-interviews-use-35-npm-packages-to-spread-malware/bleepingcomputer

The Hacker News — Fake Next.js job repos targeting developers: https://thehackernews.com/2026/02/fake-nextjs-repos-target-developers.htmlthehackernews

CSO Online — North Korean cyberspies trick developers via fake job interviews: https://www.csoonline.com/article/3479795/north-korean-cyberspies-trick-developers-into-installing-malware-with-fake-job-interviews.htmlcsoonline

CyberSecurityDive — State-linked hackers deploy malware in fake job interviews: https://www.cybersecuritydive.com/news/north-korean-hackers--fake-interview/739165/cybersecuritydive

CybersecurityNews — Beware of fake job interview challenges attacking developers: https://cybersecuritynews.com/beware-of-fake-job-interview-challenges/cybersecuritynews

Economic Times Tech / Graphalgo coverage: https://techmonk.economictimes.indiatimes.com/news/cybersecurity/graphalgo-security-alert-fake-job-interviews-are-dropping-rat-malware-on-developer-machines/118188688techmonk.economictimes.indiatimes

Dev Popper / Bluegrid — Social engineering via fake job offers: https://bluegrid.io/blog/dev-popper-how-social-engineering-exploits-developers-with-fake-job-offers/bluegrid

Git hook hardening / disabling Stack Overflow — Disable Git hooks for security reasons: https://stackoverflow.com/questions/35997624/how-to-disable-git-hooks-for-security-reasonstackoverflow

Stack Overflow — How to globally disable Git hooks: https://stackoverflow.com/questions/48135161/how-to-globally-disable-git-hooks

Confessions of a Git Beginner: Why the Terminal Stopped Scaring Me

Mon, 22 Jun 2026 06:49:46 +0000

When I started my coding journey, I thought writing code was the hard part. Then I met Git and the command line. At first, it felt like a series of incantations I had to type perfectly into the terminal, or my entire project would vanish. But after breaking a few things and pushing through the confusion, I realized Git isn't just a tool only, it's also a mindset shift.

To be completely honest, the terminal terrified me. It felt like a cold, unforgiving void where typing a single wrong character could accidentally delete my entire project or break my machine. For the first few weeks, running commands felt like shouting magic incantations into the dark and praying everything didn't blow up. But a funny thing happens when you use Git every day: the fear fades, and the mindset changes.

I’m still very much a beginner, but Git has completely changed how I think about building software. Here are the four biggest lessons version control has taught me so far.

1. Making Mistakes is Part of the Process (The Safety Net)
Before I started using Git, writing code felt incredibly high-stakes.

Git completely flipped that script. It taught me that software development, it’s about having a safety net that allows you to fail safely.

Realizing that I can ruthlessly experiment, completely mess up a file, and then simply run a command to discard those changes and reset back to safety was a massive breakthrough. Git didn't just save my code; it gave me the psychological freedom to break things on purpose just to see how they work.

2. The Art of Breaking Things Down
Git forced me to stop, breathe, and think modularly. It taught me to break big problems into micro-steps:

Isolate the feature:
Instead of working on everything in the main branch, I learned to spin up a dedicated feature branch for a single specific task.
Work in tiny increments:
Fix a small bug? Commit it. Format a file? Commit it.
Write meaningful histories:
Wrapping my head around why git commit -m "fixed stuff" is a bad idea made me a better critical thinker. Writing a clear, structured commit message forces you to explain what you changed and why.

It made me look at projects differently. I now view coding as a series of small, manageable stepping stones.

3. Communication & Collaboration
Even if you are working on a solo project, you are never truly coding alone. At the very least, you are collaborating with Future You.

There is nothing quite like looking back at a project you wrote three weeks ago and trying to figure out what your past self was thinking. Git taught me that code isn't just written for computers to execute; it's written for humans to read.

Maintaining a clean Git history, naming branches logically, and writing a solid, detailed README.md file aren't just administrative chores. They are essential communication tools. Git taught me that being a good developer means being a good teammate to whoever reads my repository next—even if that person is just me in a month.

4. Navigating the "oops" Moments

Git will throw errors at you that look like complete gibberish at first. You'll run into an unexpected merge conflict, a permission issue, or a 403 Forbidden error when trying to push to a remote repository.

In my first week, those errors made my stomach drop. I assumed I had broken everything beyond repair.

But navigating those "uh-oh" moments taught me the most valuable lesson of all: senior developers don't have fewer errors; they just have more practice solving them.

I learned to slow down, read the terminal logs closely, check my remote configurations, and realize that every single error is fixable. The terminal isn't an enemy looking to punish your mistakes; it’s just a tool waiting for clear instructions.

Repetition Builds Muscle Memory
If you're a beginner reading this and you still have to look up how to update your branch from main, delete a local branch, or fix a detached HEAD state—that is completely normal.

I still keep a cheatsheet open on my second monitor. The commands don't stick overnight, but the confidence does. Git stopped being a scary obstacle and became the ultimate developer tool. It keeps me organized, gives me permission to make mistakes, and reminds me that every big problem is just a collection of tiny, committable pieces.

If you’re hiding from the terminal, take the leap. Type git init, embrace the errors, and let yourself break things. It's the only way to learn!

️ What was the most terrifying Git error you ran into as a beginner, and how did you fix it? Let's swap horror stories in the comments!

I Added an AI Gate Before Every git push with no-mistakes ️

Sun, 14 Jun 2026 03:34:08 +0000

We are all using AI to write code now. Whether it's Claude Code, Aider, or Copilot, the speed is incredible. But there is a glaring bottleneck we don't talk about enough: AI code is often just slightly broken.

It forgets an import, misses a type definition, or fails a test.

Usually, you only find out after you push to GitHub. Your CI/CD pipeline turns red , and you end up polluting your Git history with a dozen commits titled fix: linting or fix: missing test variable.

I recently found a repository called no-mistakes that solves this brilliantly. It acts as a local proxy between your terminal and GitHub, forcing AI to test and fix its own code before anyone else sees it.

Here is why it's worth a look.

The Problem With Traditional Workflows

Right now, developers handle broken code in two ways:

The CI/CD Walk of Shame : You push code, wait 5 minutes for GitHub Actions to fail, pull the error locally, fix it, and push again.
Pre-commit Hooks (Husky) : You set up local hooks. When you try to commit, it yells at you about formatting and blocks the commit until you manually fix it.

Both methods are passive. They tell you something is broken, but they leave the cleanup to you. When you're using an AI coding agent to generate the code in the first place, manually babysitting its output defeats the purpose.

Enter `no-mistakes`

no-mistakes is a CLI tool that intercepts your git push. Instead of sending your code straight to origin, it routes it through a localized validation pipeline.

⚙️ How it actually works:

The Hidden Sandbox: When you trigger it, it creates a temporary git worktree in the background. Your active editor stays completely undisturbed.
✅ Validation: It runs your tests, linter, and build steps inside that isolated sandbox.
The AI Feedback Loop: If a test fails, it captures the error log and hands it back to an AI agent, essentially saying: "You broke this test. Fix it."
The Clean Push: Once the AI patches the code and all tests pass, it pushes the clean code to GitHub and auto-opens a Pull Request. It then deletes the temporary sandbox.

What Makes It Stand Out

The biggest differentiator is that it is active, not passive.

If a pre-commit hook fails, the process stops. If no-mistakes fails, it initiates an agentic review loop. It uses an interactive Terminal UI (TUI) to show you exactly what the AI is trying to fix. If the AI gets stuck, you can step in and provide guidance right in the terminal.

It also integrates natively with tools like Claude Code. You can literally tell your agent, "Use the /no-mistakes skill to verify and gate these changes," and it will handle the entire lifecycle.

✨ Key Features at a Glance

Non-Blocking: Because it uses hidden worktrees, you can immediately start working on your next feature while it tests and fixes the last one in the background.
Auto-Rebase: It automatically rebases your code on top of the latest main branch before testing, preventing hidden merge conflicts.
Auto-Documentation: It reviews the code changes and updates your README.md to keep documentation from going stale.
Clean PRs: You never push failing builds upstream.

️ How to Get Started

Setup takes about 30 seconds. ⚡

1. Install the CLI tool globally:

curl -fsSL https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/install.sh | sh

2. Initialize it in your project folder:

no-mistakes init

This wires up a new git remote proxy called no-mistakes.

3. Change how you push:

The next time you (or your AI) finish a feature, skip git push origin. Instead, run:

git push no-mistakes

The tool will take over, spin up the worktree, run your suites, fix the AI's slop, and open the PR for you.

Let's Discuss

As AI agents write more of our code, our tooling needs to shift from writing to verifying.

How are you currently handling AI-generated bugs in your workflow? Are you still manually running tests and fixing the AI's mistakes, or have you started automating the review loop? Let me know in the comments!

Error: pulling is not possible because you have unmerged files.

Fri, 12 Jun 2026 13:39:35 +0000

When working with Git, it's not uncommon to encounter a variety of error messages. One of the most common error messages you might come across is "Error: pulling is not possible because you have unmerged files." This error message can be frustrating, especially if you're not quite sure what it means or how to fix it. In this article, we'll take a deep dive into what this error message means, why it occurs, and most importantly, how to fix it. So, whether you're a seasoned Git veteran or a newcomer to the world of version control, keep reading to learn everything you need to know about resolving this error message and getting back to work on your project.

Why the error

When working with version control systems like Git, it's not uncommon to encounter the error message "Error: pulling is not possible because you have unmerged files." This error occurs when you try to pull in changes from a remote repository, but your local repository has changes that have not yet been merged with the remote repository.

To understand why this error occurs, it's helpful to first understand how Git manages changes. When you make changes to a file in your local repository, Git considers those changes to be "uncommitted." In order to share those changes with others, you need to "commit" them to your local repository. Once you've committed your changes, you can then "push" them to a remote repository, where they can be shared with others.

The error message "Error: pulling is not possible because you have unmerged files" is telling you that there are changes in your local repository that have not yet been merged with the remote repository. This could be because you haven't committed your changes yet, or it could be because someone else has pushed changes to the remote repository that conflict with your changes.

When you try to pull changes from a remote repository, Git compares the state of your local repository with the state of the remote repository. If there are no conflicts between the two, Git will automatically merge the changes and update your local repository. However, if there are conflicts, Git will stop the process and give you an error message.

To resolve this error, you'll need to first commit any changes you've made in your local repository, and then use Git's merge tools to resolve any conflicts. Once you've done this, you should be able to pull in changes from the remote repository without encountering any errors.

It's worth noting that this error is not an uncommon situation when working with a team on a project, as multiple people can work on the same files and push their changes to the remote repository. To avoid this error, it's a good practice to pull in changes from the remote repository before starting to work on a file, and also to commit your changes frequently and push them to the remote repository.

Some basic concepts of git

Git is a distributed version control system that allows developers to track changes in their code and collaborate with others on a project. With Git, developers can easily keep track of different versions of their code, roll back to previous versions, and merge changes made by multiple people.

One of the key concepts in Git is the "repository," which is a container for all the files and directories related to a project. When you create a new project, you can initialize a new repository using the command "git init." Once you've initialized a repository, you can start adding files to it using the command git add For example, if you have a file called main.py that you want to add to your repository, you would use the command git add main.py

Once you've added your files to the repository, you can "commit" your changes. A commit is a snapshot of your repository at a specific point in time. When you commit your changes, you're essentially telling Git that you want to save the current state of your repository. You can create a new commit using the command git commit -m 'Commit message' where Commit message is a description of the changes you made.

Another important concept in Git is the "branch." A branch is a way to separate your work on a project into different threads. By default, when you create a new repository, it has a single branch called "master." You can create a new branch using the command git branch new_branch and switch between branches using the command git checkout branch_name

One of the most powerful features of Git is its ability to collaborate with others. When you're working on a project with other people, you can use a "remote repository" to share your changes with others. A remote repository is a copy of your repository that's stored on a server. You can create a new remote repository using the command git remote add origin [URL] and then push your changes to it using the command git push -u origin master

To fetch and merge the changes made by others in the remote repository, you can use the command git pull. This command will fetch the changes from remote repository and merge them with your local repository.

Note It is recommended a good practice to always pull before pushing to a remote repository. This is particularly useful when working collaboratively in a team.

These are some of the basic commands that you can use to work with Git. However, Git is a complex tool with many features and options. To master Git, it's recommended to explore more advanced commands and concepts, such as merging, rebasing and resolving conflicts.

Useful resources to master git

Pro Git by Scott Chacon and Ben Straub: This is considered as one of the best resources for learning Git. It's available for free online and covers all the basic and advanced concepts of Git in a clear and concise manner.
Learn Git Branching by Atlassian: This is an interactive tutorial that covers the basics of Git branching. It uses a visual approach to help you understand the concepts of Git.
Git documentation: The official documentation of Git is a great resource to learn about the different commands and features of Git.
Git Immersion by EdgeCase: This is a comprehensive tutorial that covers all the basic and advanced concepts of Git. It's available for free online and includes exercises and quizzes to help you test your understanding.
Version Control with Git by Jonathan McGlone: This is a comprehensive guide that covers all the basic and advanced concepts of Git. The book is available online for free and covers all the basic and advanced concepts of Git.
Git Hub Learning Lab: A series of interactive tutorials and exercises that can help you learn Git by doing.
Git Tutorial on Codecademy: An interactive tutorial that covers the basics of Git and how to use it to collaborate on a project.

These resources are considered as good starting point for those who want to learn Git and master it. They provide a comprehensive and in-depth understanding of the different features and concepts of Git, along with examples and interactive exercises to help you practice and improve your skills.

Conclusion

Git is a powerful tool that allows developers to track changes in their code, collaborate with others and maintain different versions of the code. Basic commands like git init, git add, git commit, git branch, git push and git pull are essential to work with git and keep track of the changes in your code.

Why GitHub 2FA Won’t Save You From Infostealers

Tue, 09 Jun 2026 22:26:57 +0000

Imagine this: it is 3:00 AM. Your laptop is closed, your computer is off, and you are asleep. Suddenly, your phone buzzes with an email notification from GitHub: “Security Alert: Force-push detected on your repository.”

You jump out of bed, open GitHub, and start checking everything. Your active web sessions look normal. Your security log does not show a strange login. There is no obvious “new token generated” event. No one seems to have entered your account through the browser.

But when you open your repositories, something is wrong. A strange script has been pushed into your codebase. Your package scripts have been modified. Your build files have been touched. The new code is designed to steal your production environment variables.

The scary part is this: GitHub 2FA can be enabled, and this can still happen. Not because 2FA is useless, but because 2FA mainly protects the login screen. It does not automatically protect every credential that already exists on your machine. And that is exactly where modern infostealers attack.

TL;DR

GitHub 2FA helps protect your account login, but it may not save you if malware steals an already-authorized Git credential from your local machine.

If you use HTTPS Git remotes, your system may cache a Personal Access Token, OAuth token, GitHub CLI token, VS Code token, or another GitHub-related credential through your OS credential manager or Git credential helper. That token may be encrypted while stored, but once malware runs inside your active user session, it may be able to ask the same local tools Git uses to retrieve a usable credential.

Once the attacker has a valid token, they may not need your password, browser session, or 2FA code. They can push code from somewhere else. And if your repository is connected to an auto-deploy platform, that push can quickly become a production incident.

The fix is not just “enable 2FA.” You also need to revoke exposed tokens, clear cached Git credentials, move from HTTPS remotes to passphrase-protected SSH keys, disable direct force-pushes, protect your production branch, scan your codebase for malicious changes, and reduce the secrets available during CI/CD builds.

The False Sense of Security Around GitHub 2FA

Most developers hear “2FA enabled” and feel safe. To be fair, 2FA is important. It protects your GitHub account from a very common attack: someone stealing or guessing your password and trying to log in through the website.

But Git does not always work like a normal website login. When you push code from your terminal, VS Code, GitHub Desktop, or another development tool, you are often not typing your GitHub password every time. Instead, your machine uses an already-authorized credential.

That credential might be a Personal Access Token, an OAuth token, a GitHub CLI token, a VS Code GitHub authentication token, or another credential stored through a Git credential helper. This is where the problem starts.

2FA may stop a new login attempt, but if malware steals a token that has already been authorized, the attacker may be able to act as you without ever touching the 2FA flow. They are no longer trying to break into the front door. They found a copied key.

How Infostealers Abuse Local Developer Environments

Modern infostealers do not always need to “hack GitHub.” Sometimes, they only need to compromise the developer’s machine.

That compromise can happen through things developers interact with every day: a fake VS Code extension, a malicious npm package, a compromised dependency, a poisoned postinstall script, a fake CLI tool, a cracked app, a malicious browser extension, or a script copied from the internet without proper inspection.

Once malware runs on your computer, it may inherit your normal user permissions. That part matters. Your operating system may trust processes running under your user account, and your Git tools may also trust that same environment.

So even if your token is not lying around as plain text on disk, it can still become exposed when a trusted local tool retrieves it for Git operations. In simple terms: the credential may be protected while stored, but it can still be returned in usable form when your local Git workflow asks for it. That is the gap infostealers target.

The Local Credential Problem

Many developers clone repositories using HTTPS URLs like this:

https://github.com/username/repository.git

When using HTTPS, Git usually needs a credential to authenticate pushes and private repository access. To avoid asking you for a password or token every single time, Git can use a credential helper.

Depending on your OS and setup, this credential may be stored or retrieved through macOS Keychain, Windows Credential Manager, Linux libsecret, Git Credential Manager, GitHub CLI, VS Code authentication helpers, or other developer tools.

This is convenient, but convenience creates a security tradeoff. If a malicious script can run inside your active user session, it may be able to interact with the same credential system your Git client uses. That means the attacker does not need your GitHub password. They do not need your 2FA code. They just need the already-authorized credential your machine uses to push code.

The 3:00 AM Attack

Here is the attack flow in plain English.

First, malware runs on your machine. Maybe it came from a malicious package, a fake extension, or a script you ran while trying to fix something. The malware may only need to run once.

Next, it looks for developer credentials. It may search for Git credentials, GitHub CLI tokens, npm tokens, cloud provider keys, .env files, SSH keys without passphrases, browser sessions, deployment tokens, and CI/CD-related secrets.

Then, if your GitHub HTTPS credential can be retrieved in usable form, the malware sends it to the attacker. At that point, the attacker does not need to keep your laptop online. The credential can be used from another machine.

Hours or days later, an automated server controlled by the attacker uses that credential to push malicious code to your repositories. It may force-push, modify build files, alter package scripts, or target multiple repositories at once. Because the push is authenticated with a valid credential, it may look like a legitimate Git operation.

That is why you can wake up confused. You may not see a new login. You may not see a new browser session. You may not see a fresh “2FA passed” event. The attacker did not necessarily log in through the web UI. They reused a credential that already existed.

This is why the attack feels invisible. Not because nothing happened, but because you are looking in the wrong place.

Why This Becomes Worse With Auto-Deploy Platforms

A repository breach is already bad, but for modern developers, a repository breach can quickly become a production breach.

Many projects are connected to auto-deploy platforms like Vercel, Netlify, Render, Railway, Fly.io, Dokploy, Coolify, GitHub Actions, or self-hosted CI/CD pipelines. This creates a dangerous chain reaction.

The attacker pushes malicious code. Your deployment platform sees a new commit. The platform pulls the code. The build starts automatically. The malicious code runs during the build. And build time is often when secrets are available.

This is called poisoned pipeline execution. The attacker does not only want your source code. They want the secrets your deployment system can access: database URLs, API keys, AWS credentials, Firebase credentials, payment provider keys, SMTP credentials, private service tokens, and production environment variables.

The payload can hide inside files developers rarely inspect carefully, such as package.json scripts, postinstall hooks, vite.config.js, next.config.js, tailwind.config.js, build scripts, deployment scripts, or custom CLI files.

That is why this attack is dangerous. It does not stop at GitHub. It can move from your machine, to your repository, to your CI/CD pipeline, to your production environment.

The Real Lesson: Do Not Treat Git Credentials Like Permanent Keys

The real problem is not just HTTPS. The real problem is permanent, reusable credentials that can be copied and used elsewhere.

A cached HTTPS token is powerful. If an attacker gets the raw token, they may be able to use it from another machine, depending on its scope and validity. That is a risky security model for sensitive projects.

A better model is explicit approval. Your Git push should require something that is not easily copied and reused remotely.

This is where SSH keys with strong passphrases become useful. With SSH, authentication depends on a private key stored on your machine. If you protect that private key with a strong passphrase, an attacker cannot simply copy one token string and immediately use it from a cloud server.

To be clear, this does not make your machine invincible. If malware is running on your computer, you still have a serious problem. Malware can tamper with files, watch your activity, steal other secrets, or wait for you to unlock something.

But passphrase-protected SSH removes one major weakness: a silently stolen HTTPS token that works anywhere in the world.

Practical Lockdown Guide

The goal is to move from this:

“My machine silently provides a reusable token whenever Git needs it.”

To this:

“A push requires my local SSH key and my manual passphrase approval.”

Phase 1: Revoke Existing GitHub Tokens

First, assume any old credential may already be exposed. Do not only delete it from your laptop. If the attacker already copied it, deleting it locally is not enough. You need to revoke it from GitHub.

Go to:

GitHub → Settings → Applications

Check both:

Authorized OAuth Apps
Authorized GitHub Apps

Revoke anything you do not recognize. Pay close attention to tools with broad repository access, such as old IDE integrations, old Git clients, abandoned CLI tools, deployment services you no longer use, random apps you tested once, or anything with full repository permissions.

Also check your tokens:

GitHub → Settings → Developer settings → Personal access tokens

Review both classic and fine-grained tokens. Delete anything you do not actively use. For tokens you must keep, reduce the scope. A token should not have full account access when it only needs access to one repository.

Phase 2: Clear Cached GitHub HTTPS Credentials Locally

Next, clear GitHub credentials from your local credential helper. This helps prevent your machine from silently reusing old HTTPS authentication.

macOS

security delete-internet-password -s github.com

Depending on your setup, you may also need to inspect Keychain Access manually and remove GitHub-related internet passwords.

Windows

(echo protocol=https & echo host=github.com & echo.) | git credential reject
cmdkey /delete:LegacyGeneric:target=git:https://github.com

You can also open Windows Credential Manager and remove GitHub-related credentials manually.

Linux

printf "protocol=https\nhost=github.com\n\n" | git credential reject

Depending on your credential helper, you may also need to clear entries from libsecret, GNOME Keyring, KWallet, or a plaintext Git credential file if one was configured.

Verification check

Run this locally:

printf "protocol=https\nhost=github.com\n\n" | git credential fill

If nothing useful prints, your local Git credential cache is likely clean. If a username or password/token appears, do not share the output anywhere. Clear the credential again and inspect your credential helper configuration.

Some IDEs and developer tools try to make Git authentication easier by automatically sharing credentials with your terminal. That is convenient, but if your goal is strict manual approval, you should reduce this automation.

In VS Code, open settings and search:

git.terminalAuthentication

Disable it. This helps prevent VS Code from automatically providing GitHub authentication to terminal Git commands. Also review the GitHub Pull Requests extension, GitHub authentication, and any third-party Git-related extensions you installed. Remove what you do not need.

Phase 4: Generate a Passphrase-Protected SSH Key

Now create a dedicated SSH key for GitHub:

ssh-keygen -t ed25519 -C "*Emails are not allowed*"

When asked where to save the key, you can accept the default path:

~/.ssh/id_ed25519

When asked for a passphrase, do not leave it empty. Use a strong passphrase you can remember. This passphrase protects your private key if someone tries to copy it.

Phase 5: Add the SSH Public Key to GitHub

Copy your public key.

macOS

pbcopy < ~/.ssh/id_ed25519.pub

Windows PowerShell

Get-Content ~/.ssh/id_ed25519.pub | Set-Clipboard

Linux

cat ~/.ssh/id_ed25519.pub

Then go to:

GitHub → Settings → SSH and GPG keys → New SSH key

Give it a clear title, such as:

Personal MacBook Terminal SSH Key

Paste the public key and save it.

Never upload your private key. Your private key is the file without .pub.

Phase 6: Create an SSH Config

Create or edit your SSH config file.

macOS/Linux

nano ~/.ssh/config

Windows

notepad %USERPROFILE%\.ssh\config

Add this:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Avoid adding automatic keychain options if your goal is to require manual passphrase approval. On macOS, for example, avoid blindly adding settings that store the passphrase in Keychain unless you intentionally want that convenience.

On macOS/Linux, secure the permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 600 ~/.ssh/config

Phase 7: Convert Your Repositories From HTTPS to SSH

Your local projects may still point to HTTPS remotes. Check a project by running:

git remote -v

If you see something like this:

https://github.com/username/repository.git

Change it to SSH:

git remote set-url origin *Emails are not allowed*:username/repository.git

Now test SSH authentication:

ssh -T *Emails are not allowed*

You should see a passphrase prompt for your SSH key. After entering the passphrase, GitHub should respond with a message saying you authenticated successfully, but GitHub does not provide shell access. That means SSH authentication is working.

Optional: Automate the Cleanup for Multiple Repositories

If you have many repositories on your machine, changing every remote manually can be stressful. That is why I built an open-source tool called git-malware-remediator.

The tool was created to help developers recover faster after this kind of Git/GitHub compromise. Instead of manually opening dozens of folders and checking every .git config one by one, it can help scan your local projects, detect HTTPS GitHub remotes, convert them to SSH format, and look for suspicious traces that may indicate malware activity in your codebase.

It can also help with codebase cleanup by scanning for common malicious patterns, suspicious scripts, altered Git configurations, and possible payload traces that may have been introduced during the attack. This makes it useful not only for switching repositories from HTTPS to SSH, but also for reviewing and fixing compromised projects after a suspected malware incident.

You can get it here:

git clone https://github.com/JC-Coder/git-malware-remediator.git
cd git-malware-remediator

Then follow the README to run the scan, review the findings, and apply the recommended fixes.

Protect the Repository, Not Just Your Laptop

Local security is only one side of the problem. You also need to harden the repository itself.

Even if your machine is compromised, the attacker should not be able to destroy your production branch with one push.

1. Disable Direct Force-Pushes

Go to:

Repository → Settings → Branches → Branch protection rules

Create a rule for your production branch, usually main or master. Make sure force-pushes are not allowed. If possible, enforce this rule for administrators too.

A stolen credential should not be able to rewrite your production history without resistance.

2. Require Pull Requests Before Merging

Do not allow direct pushes to production branches. Require pull requests, reviews, and status checks.

This creates a human checkpoint between a compromised local machine and production deployment.

A good rule is simple:

No code reaches production without review.

Even if you are a solo developer, use pull requests for important projects. Future you is also a reviewer.

3. Protect CI/CD Secrets

Many developers accidentally expose too many secrets during build time. That is dangerous. If a malicious script runs during build, it may be able to read whatever secrets the build environment can access.

Do not give build scripts access to production secrets unless absolutely necessary. Prefer runtime secrets where possible. Keep database credentials inside the server runtime, avoid exposing production .env values during frontend builds, separate preview secrets from production secrets, rotate secrets after any suspected compromise, and review which environment variables your deployment platform exposes during build.

The goal is simple: if a build script gets poisoned, it should not have everything it needs to drain your production environment.

4. Pin and Review Dependencies

Infostealers often reach developers through the package ecosystem, so do not treat dependencies as harmless.

Be careful with packages that have very few downloads, recently changed maintainers, strange install scripts, obfuscated code, typosquatted names, or unnecessary access to your file system.

Also watch your package.json scripts. A malicious script can hide in places like this:

{
  "scripts": {
    "postinstall": "node suspicious-file.js",
    "build": "node hidden-script.js && vite build"
  }
}

Your scripts are part of your security boundary. Treat them that way.

5. Rotate Secrets After a Suspected Breach

If you suspect your repository was modified by malware, do not only revert the commit. Assume secrets may have been exposed.

Rotate GitHub tokens, npm tokens, database passwords, API keys, cloud credentials, deployment tokens, webhook secrets, SMTP credentials, payment provider keys, and any secret that was available on the machine or CI/CD environment.

Reverting code fixes the repository. Rotating secrets fixes the damage that may have already happened.

What To Do If You Wake Up To a Suspicious Force-Push

If you receive a GitHub alert or notice strange repository changes, act quickly.

First, disconnect the machine from the internet to stop possible ongoing exfiltration. Do not keep building or running the project, because the malicious code may be inside build scripts. Revoke GitHub tokens immediately, including OAuth apps, GitHub Apps, and suspicious integrations.

Next, rotate deployment and production secrets. Assume anything available to the repository or build pipeline may be exposed. Check repository activity, branch history, force-push events, and recent commits. If the repository belongs to an organization, check organization audit logs if available.

Also inspect CI/CD logs. Look for strange build commands, unexpected network requests, changed build scripts, or unknown environment variable access patterns. Restore from a known-good commit, and do not trust the latest branch state until you inspect it.

If malware ran on your machine, consider the machine untrusted until you properly clean it. In serious cases, a full OS reinstall may be safer than trying to manually remove everything.

The Point Is Not “2FA Is Bad”

2FA is not bad. You should still use it. In fact, you should use strong 2FA, preferably with passkeys or hardware security keys where possible.

The point is this: 2FA protects authentication events. It does not automatically protect every credential, token, key, secret, and build pipeline connected to your development workflow.

Modern developer security is bigger than your GitHub password. You need to protect your local machine, Git credentials, SSH keys, IDE, dependencies, repository settings, CI/CD pipeline, and production secrets.

Attackers know developers are the gateway to production. That is why they target our tools.

Conclusion

Convenience is useful, but too much invisible convenience can become dangerous.

Cached credentials, automatic IDE authentication, broad tokens, direct pushes, and auto-deploy pipelines all make development faster. They also make attacks faster.

GitHub 2FA is important, but it is not a magic shield. If an infostealer gets a valid local Git credential, it may bypass the login screen entirely and operate through the same trusted path your tools use every day.

So draw a harder line. Revoke old tokens. Clear cached HTTPS credentials. Move sensitive repositories to passphrase-protected SSH. Disable force-pushes. Require pull requests. Limit build-time secrets. Scan your codebase for malicious changes. Fix suspicious Git configurations before trusting your projects again.

And treat your local developer environment like part of your production security system.

Because it is.

Happy coding, and secure your tools before someone else uses them against you.

Git: Best Practices for Professionals

Thu, 04 Jun 2026 07:29:58 +0000

Developers working in fast-moving teams often deal with overlapping work, long-running features, and reviews that depend on clear and reliable history.

This guide focuses on common Git problems developers face when working in teams and highlights the techniques that keep workflows stable, predictable, and easy to maintain.

Handling Merge Conflicts the Right Way

You created a Pull Request (PR) and when it’s time to merge it to main you are hit with a Merge Conflict on the UI. Here’s how to handle the conflict efficiently and seamlessly.

Note: Resolving the actual conflict will always be a manual task at the code level.

1. Check your status when on your feature branch

git status

2. Checkout to the main branch — the one your PR needs to be merged to

git checkout main

3. Then git pull to get latest main in your local

git pull

4. Switch back to the feature branch the PR is based on

git checkout feature-branch

5. Execute the Merge Command:

git merge main    # (this tries to merge the main branch to the feature branch)

After running the merge command you will get conflicts in certain files, these conflicts should replicate the original merge conflicts being faced in the Pull Request.

Now the conflicts need to be merged manually and can incur code loss, which is fine if both the main and feature branches are pushed in origin.

git status               
git add resolve files    # add all the files with resolved code
git commit               # just git commit; without the -m flag
git push -u origin HEAD

Running git commit will auto create a Merge Commit so you don’t need to provide any custom message.

After pushing to origin, the PR should not show any conflicts and the commit history in the feature branch should have a commit with an auto-merge message like this: Merged PR 123: Updated the UI with new design.

Reverting a Pushed Commit

Often at times we push and merge a commit to the main branch but then things go wrong and we end up introducing unexpected bugs into production code.

This is where you can safely revert the bad commit until the issue is identified. Here is how to do it safely:

1. Update your local repository

git checkout main
git pull

2. View the recent commits

git log

Here find the bad commit and copy the commit hash, which should look something like this: c41975d1dae1cc69b16ad8892b8c77164e84ca39.

3. Revert the individual commit

git revert c41975d1dae1cc69b16ad8892b8c77164e84ca39

git revert <commit-hash> automatically creates a commit message with a revert message:

Revert “Updated the UI with new design” This reverts commit c41975d1dae1cc69b16ad8892b8c77164e84ca39.

4. Verify and Push to main

git status
git push -u origin HEAD

Verify using git status that you are on the main branch and your local is a commit ahead of origin. git push to push the reverted code changes to origin.

Using stash the Right Way

Imagine you are working on a feature and have some useful changes on local but you have to pull the latest code from main to work on top of, so you do a git pull but end up getting the following message:

error: Your local changes to the following files would be overwritten by merge:
    <file names>
Please commit your changes or stash them before you merge.
Aborting

Here git already gives you a hint of what you need to do.

Using git stash the right way:

git stash
git pull
git stash apply    # this reapplies the latest stashed changes in your local

Note: this might give you merge conflicts.

This can be unsafe if you forget to reapply the changes immediately and lose track of the stashed code, so it is recommended for only small changes.

A safer approach for larger changes would be to ensure you checkout to a new branch and push your changes to origin. Which allows you to freely pull the latest code and merge it to your working branch without losing your code.

Note: this might also give you merge conflicts.

Resetting to a Previous Commit

What if you are working locally and have a few bad commits which you want to get rid of.

When can this happen:

You were resolving a merge conflict but end up with bad commits.
You have some unwanted commits in your local which you do not want or even remember — can happen if you restart work on an old feature after a long time.
Or you get the following message and git pull raises merge conflicts.

Your branch and 'origin/<branch>' have diverged,
and have 4 and 2 different commits each, respectively.
 (use "git pull" to merge the remote branch into yours)

If you are sure your local commits are unwanted or backed up, you can get rid of them by resetting your commit history by running the following command:

git reset --hard HEAD~

CAUTION: This command destroys your local commits permanently!

This resets the local HEAD to one previous commit.

If you have multiple local unwanted commits, you can run the command multiple times and sync cleanly using a git pull:

git reset --hard HEAD~
git reset --hard HEAD~
git reset --hard HEAD~
...
git pull

This will reset the HEAD multiple times to a stable commit and then you can sync with the origin with no issues.

Cherry Picking

Cherry-picking lets you take a specific commit from any branch and apply it onto another branch.

It is a useful command which lets you pick up all changes in a commit from one branch to another, given that the 2 parent branches have similar history.

Possible useful scenarios:

You fixed a bug on one branch e.g. “the dev branch”, and need the same fix to be applied on another branch e.g. “the release branch”.
You accidentally committed changes to a wrong branch and want to move the commit to the correct branch.

Here is how to cherry-pick a commit safely from branch A to branch B:

1. View the recent commits on branch A

git checkout branch-a
git log

Here find the commit to copy and copy its hash.

2. Switch to branch B

git checkout branch-b

3. Apply the individual commit

git cherry-pick c41975d1dae1cc69b16ad8892b8c77164e84ca39

On a successful cherry pick you will get the following message:

[main abc123] Fix login bug
 Date: Tue Dec 1 12:00:00 2020 +0200
 2 files changed, 10 insertions(+), 3 deletions(-)

After which it should be safe to push to origin.

Hope this guide helps.

Also, check out the guide Best Git Practices for Beginners if you haven’t already.

Git and GitHub concepts

Mon, 01 Jun 2026 17:08:20 +0000

Introduction

I will be breaking down git and GitHub from beginner basics to a more advanced level in this article.I hope this structured approach will help you build a solid foundation moving forward.

what is Git

Git is a distributed version control system created by Linus Torvalds in 2005.It is designed to handle everything from small to very large projects with speed and efficiency.Unlike centralized version control systems,Git allows every user to have a complete copy of the repository,including its history on their local machine.This means you can work offline and still have access to the full project history.

version control is a system that records changes to files over time so that you can recall specific versions later.
It's essential for collaborative work,allowing multiple people to work on the same project without conflicts.

Instillation

To start using Git,you need to install it on your computer.You can download Git from the official website git-scm.com. Installation is straightforward and available for various operating systems,including Windows,macOS and Linux.

Basic configuration(letting git know you)

Once Git is installed,you should configure it with your username and email.This information will be associated with your commits and help others identify who made specific changes.

You can fill in you name and gmail using a syntax:
git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"

Creating your first repository

To create a new Git repository,navigate to your project directory.

This command initializes a new Git repository,creating a hidden directory that stores all the version control information.

Basic git commands

1.Checking the status

To see the current status of your repository including staged and unstaged changes,use:

This command provides a snapshot of your working directory and staging area helping you understand what changes are ready to be committed.

2.Adding changes

Before you can commit changes,you need to stage them.You can stage individual files or all changes at once.Below is the basic syntax you can follow.You can add any file you want from your file explorer

3.committing changes

Once your changes are staged,you can commit them to the repository.Each commit should have a descriptive message explaining what changes were made

4.Branching and Merging

Git encourages the use of branches,allowing you to work on new features or fixes in isolation without affecting the main codebase.Once your work is complete,you can merge it back into the main branch.

a.Creating a branch

Branches allow you to work on different features or fixes without affecting the main codebase.To create a new branch,use the git branch and write the branch name

b.Switching branches

Switching to a new branch you use the git checkout.

5.Merging branches

Once you’ve completed work on a branch,you can merge it back into the main branch (often called main or master)

If there are conflicts (changes that cannot be automatically merged),Git will prompt you to resolve them manually.

Remote Repositories with GitHub

what is GitHub?

GitHub is a web-based platform that uses Git for version control. It provides a user-friendly interface for managing Git repositories and facilitates collaboration among developers. GitHub allows you to host your code online,making it accessible to others and enabling collaborative work.

Creating a GitHub account

To use GitHub,you need to create an account at gitHub.com.Once registered,you can create repositories,contribute to others' projects and manage your own code.

Connecting Your Local Repository to GitHub

To push your local repository to GitHub,you first need to create a new repository on GitHub.After that,link your local repository to the remote one

This command sets up a connection to the remote repository,allowing you to push and pull changes.

Pushing and Pulling changes

1.pushing changes

To upload your local commits to GitHub,use the git push and writing the branch name as shown below:

This command sends your changes to the remote repository and making them available to others.

2.Pulling changes

To fetch and merge changes from the remote repository into your local branch,use the git pull as shown below:

This command ensures your local repository is up to date with the latest changes made by others.

Advanced Git concepts

1.Rebasing

Rebasing is a powerful feature that allows you to integrate changes from one branch into another.It rewrites the commit history and making it linear and cleaner.

2.Stashing

If you need to switch branches but aren’t ready to commit your changes,you can stash them temporarily.

You can also apply the stashed changes back to your working directory by adding apply command:

Resolving merge conflicts

When merging branches,conflicts may arise if changes overlap.Git will mark these conflicts in the affected files.You’ll need to manually resolve them by editing the files then staging and committing the resolved changes.

Collaborating on GitHub

1.Forking Repositories

Forking allows you to create a personal copy of someone else's repository.This is useful for making changes without affecting the original project.You can fork a repository directly from GitHub.

2.Pull request

Once you’ve made changes in your forked repository,you can propose these changes to the original repository by creating a pull request.This allows the original repository owner to review your changes and merge them if they approve.

Best practices for using Git and GitHub

1.Commit Often:Make small,frequent commits with clear messages.This makes it easier to track changes and understand the project history.

2.Use Branches:Keep your main branch clean by using branches for new features or bug fixes.This helps isolate changes and reduces the risk of introducing bugs.

3.Write Good Commit Messages:Clearly describe what changes were made and why.Good commit messages help others (and your future self) understand the project’s history.

Online courses

Platforms like Coursera,Udemy and freeCodeCamp offer comprehensive courses on Git and GitHub.

Conclusion

By following this detailed guide,you can build a strong foundation in Git and GitHub,progressing from a beginner to an expert level.Start with the basics,practice regularly and explore advanced features as you become more comfortable.This knowledge will not only enhance your coding skills but also improve your ability to collaborate effectively in team environments.I hope you found it useful.Ciao.

How Diff Algorithms Work: Myers Algorithm Explained Simply

Sun, 17 May 2026 19:23:18 +0000

Introduction: The Hidden Engine Behind Code Collaboration

Every time you execute git diff or review a pull request on GitHub, a clever algorithm runs silently in the background. It calculates the exact, minimum sequence of additions and deletions needed to change your old file into your new file.

A bad diff algorithm would tell you that you deleted an entire function and rewrote it, just because you added a single space. A good algorithm, however, understands the logical way humans write code.

In this guide, we will explore the Myers Diff Algorithm—the standard tool behind Git—in plain English.

Section 1: The Core Problem - "Edit Distance"

At its heart, comparing text is about finding the "edit distance." Imagine you have two versions of a document. Your goal is to find the absolute shortest list of edits (inserting or deleting lines) that turns Version A into Version B.

If a computer simply guessed every possible combination of edits, it would take centuries to compare two large code files. We need a smarter shortcut.

Section 2: The Magic Shortcut (Longest Common Subsequence)

The best shortcut is finding what hasn't changed. This is called the Longest Common Subsequence.

If we can find the longest list of lines that exist in both files in the exact same order, then everything else is just a simple addition or deletion.

A Simple Example

Imagine two short grocery lists:

List A (Old): ["apple", "banana", "cherry", "date"]
List B (New): ["apple", "blueberry", "cherry", "elderberry"]

The longest sequence they share is: ["apple", "cherry"].

Because we know these lines match perfectly, we easily know what happened to the rest:

"banana" is only in List A -> Deleted
"blueberry" is only in List B -> Inserted
"date" is only in List A -> Deleted
"elderberry" is only in List B -> Inserted

Section 3: The Genius of the Myers Algorithm

Finding that shared sequence can still be slow. In 1986, computer scientist Eugene Myers invented a brilliant way to speed this up. Instead of comparing text line-by-line in a massive, slow table, he turned the problem into a game of finding the shortest path on a map.

The Grid Map System

Imagine a grid where:

Moving Right means adding a line from the new file.
Moving Down means deleting a line from the old file.
Moving Diagonally means keeping a matching line.

The "cost" of moving diagonally is zero—it's a free move because the lines match perfectly! The Myers algorithm simply looks for the fastest path from the top-left of the map to the bottom-right, taking as many "free" diagonal moves as possible.

Because it prioritizes these free moves, it skips doing unnecessary calculations and runs almost instantly, even on massive project files.

Section 4: Why Git Uses Myers (and When It Struggles)

The Myers algorithm is incredibly fast, which is why Git uses it by default. However, because it is purely mathematical, it doesn't understand programming languages.

Sometimes, it gets confused by closing brackets } and matches them incorrectly, creating a messy view. If you ever see a weird diff full of brackets, you can tell Git to use a slightly different approach:

git diff --diff-algorithm=patience : This forces Git to focus on unique lines (like function names) rather than common symbols (like brackets), making the output much easier for humans to read when code has been heavily moved around.

Conclusion

The efficiency of our daily code reviews relies on the elegant logic of the Myers Diff Algorithm. By turning a massive text comparison problem into a simple path-finding game, it allows developers to collaborate quickly and seamlessly without ever noticing the complex math happening behind the scenes.

Forking CoverLetterGPT: What I Learned Rebuilding an AI SaaS from an Open-Source Starter

Sun, 17 May 2026 11:53:32 +0000

One of the better ways to learn a stack is to take a working app and rebuild it your way. I forked CoverLetterGPT — an open-source AI cover letter generator originally built by Vince Loewe as a flagship example app for the Wasp framework — and used it as a launchpad to learn full-stack AI app development. This post is about what I changed, what surprised me, and what I'd do differently.
Credit where it's due: original project at https://coverlettergpt.xyz, source at github.com/vincanger/coverlettergpt. Everything below is about my fork and what I learned from the exercise.
Why fork instead of building from scratch?
Greenfield projects teach you architecture decisions. Forks teach you about integration. CoverLetterGPT has:

OpenAI integration for the actual letter generation
Stripe for paid tiers
Google OAuth for sign-in
Prisma + Postgres for persistence
React + Chakra UI on the frontend
Wasp wiring all of it together

Forking gave me a working baseline for every one of those pieces. The learning came from changing one thing and watching what broke.
What Wasp actually does (and why it surprised me)
Wasp is a config-as-code framework for full-stack apps. You declare your entities, routes, auth methods, and jobs in a .wasp file, and the framework generates the boilerplate around your React + Node code. Coming from Next.js, it felt strange — until I realized how much code it removed.
A rough comparison:
ConcernNext.jsWaspAuthWire up NextAuth/Auth.js, configure providers, write callbacksDeclare auth: { ... googleAuth } in the wasp fileDB queriesWrite Prisma queries + tRPC/route handlersDeclare a query or action, write the functionBackground jobsWire up BullMQ / InngestDeclare a job, write the functionEmailNodemailer + your own abstractionemailSender: { provider: SendGrid }
It's not magic — it's just opinionated code generation. But it makes the integration work fast, which is exactly what you want when you're learning.
What I changed in my fork
Things I actually built on top of the original:

Prompt rework. The original prompt is good but generic. I rebuilt the prompt to extract structured fields from the job posting (role, seniority, top 3 required skills, tone hints) before generating the letter, so the output references specifics instead of platitudes.
Streaming responses. The original waits for the full completion. I added server-sent events so the letter streams token-by-token. Better UX, and it taught me how to plumb a stream through Wasp's API actions.
Versioning. Each generation saves as a versioned draft, so users can compare "tone: confident" vs "tone: humble" side by side instead of regenerating blindly.
Cost guardrails. Per-user daily token cap, falling back to a cheaper model after the cap. Critical if you ever plan to actually expose an OpenAI app to the internet.
Auth providers. Added GitHub OAuth alongside Google — useful for the developer-leaning audience I had in mind.

Things that broke (and what they taught me)

Stripe webhooks in local dev — I'd never wired Stripe end-to-end before. stripe listen --forward-to and idempotent webhook handlers are the lessons.
Prisma migrations on a forked schema — changing the schema after the upstream had already migrated meant I had to be careful with migration history. Lesson: branch the migration history early.
OpenAI rate limits under streaming — streaming responses count differently against limits; I had to add backoff that handles partial completions.
Wasp's escape hatches — Wasp is opinionated, but there are places (custom middleware, raw routes) where you drop into Express. Knowing when to fight the framework vs use the escape hatch is the actual skill.

Would I use Wasp for a production project?
Honestly, for a small-to-medium SaaS with standard requirements (auth, DB, payments, jobs, email) — yes. The boilerplate it removes is exactly the boilerplate I find tedious in Next.js + tRPC + NextAuth + BullMQ + Resend stacks. For anything with unusual architecture (heavy real-time, custom infra, microservices) — probably not.
The honest answer is: forking CoverLetterGPT taught me Wasp faster than any tutorial would have, because I had skin in the game. If you're looking for a way to learn a new stack, find a working open-source app in it and break things.

https://coverlettergpt.xyz

Happy to answer questions about the fork, the framework, or any of the integrations in the comments.

git-sfs: Large File Storage Without the LFS Server

Wed, 13 May 2026 16:37:11 +0000

The Problem

You added a 2 GB dataset to a repo. Now git clone takes 10 minutes, CI downloads the full history on every run, and GitHub is billing you per GB transferred. You switch to Git LFS - and now you need a server, a token, and a storage plan. You try DVC - and now you need Python, a pipeline config, and lock files that conflict on every PR.

None of this is the actual problem. The actual problem is: large files don't belong in Git objects. Everything else is overhead.

Meet git-sfs

SFS stands for Symbolic File Storage. The name is deliberate - it's Git LFS with the L swapped for S. Git LFS replaces large files with opaque pointer files and routes bytes through a proprietary server protocol. git-sfs replaces large files with plain symlinks that Git already understands natively, and routes bytes through rclone to any remote you already have.

No new protocol. No server. No pointer file format to decode. Just symlinks.

How It Works

The model is three sentences:

Git tracks symlinks.
git-sfs stores file bytes.
rclone moves files.

When you run git-sfs add data/train-000.tar.zst, here's what happens:

The file is hashed with SHA-256
Bytes are stored in <cache>/files/sha256/ab/<hash> - write-once, read-only
The original path becomes a relative Git symlink pointing into the cache

data/train-000.tar.zst -> ../.git-sfs/cache/files/sha256/ab/<hash>

data/train-000.tar.zst opens normally. Git commits a 70-byte symlink. Your repo stays fast.

Why Not Git LFS?

Git LFS solves the storage problem but adds a server problem. You need an LFS endpoint, pay per-GB transfer fees on GitHub, and the pointer-file format is an opaque internal detail.

git-sfs remotes are plain rclone destinations - S3, GCS, Azure Blob, Backblaze B2, SFTP, a local path, anything rclone supports. You can rclone ls your remote and see exactly what's there. No magic.

One Binary, No Runtime

git-sfs is written in Go. It ships as a single static binary - no Python environment, no runtime, no version conflicts. Drop it on any machine and it runs.

Quick Start

# Install (macOS/Linux, arm64 and x86_64)
curl -LsSf https://github.com/Red-Eyed/git-sfs/releases/latest/download/install.sh | sh

# Init and configure
git-sfs init        # creates .git-sfs/config.toml
# edit config.toml: set remote backend, path, rclone config
git-sfs setup       # bind local cache

# Add files
git-sfs add data/
git add .git-sfs/config.toml data/
git commit -m "track datasets"

# Sync to remote
git-sfs push

On another machine:

git clone <repo> && cd <repo>
git-sfs setup
git-sfs pull        # download only what you need

You can also pull a subset - useful when one machine only needs validation data:

git-sfs pull data/validation/

Safety by Design

Data loss in a dataset management tool is unacceptable, so git-sfs has a few hard rules:

Hash-verify at every boundary - after hashing, after download, after copy. A corrupted file is rejected, not silently accepted.
Atomic writes - temp file + rename everywhere. An interrupted push or pull never leaves a partial file.
Cache files are immutable - write-once, then write-protected. Accidental overwrites are impossible.

The verify command is designed for CI:

git-sfs verify              # presence check (fast)
git-sfs verify --with-integrity data/  # rehash cached + remote files (thorough)

And doctor checks your entire setup - config, cache, rclone binary, remote connectivity - in one shot:

git-sfs doctor

What's Different from dvc, git-annex, etc.?

Tool	Requires	Remote	PR-friendly?
Git LFS	LFS server	proprietary protocol	✅
DVC	Python, pipelines	S3/GCS/etc via SDK	❌
git-annex	Haskell runtime	many backends	❌
git-sfs	rclone	anything rclone supports	✅

DVC stores large file metadata in .dvc sidecar files and a dvc.lock that encode pipeline state. When two branches touch the same dataset, merging those lock files creates conflicts that have no meaningful resolution in a pull request - reviewers see .dvc diffs, not data diffs, and the merge problem is fundamentally DVC's, not Git's.

git-annex stores its metadata in a separate orphan branch (git-annex). That branch never appears in a normal git log or PR diff, so reviewers have no visibility into what large files changed or why. Merging the annex branch is a separate out-of-band operation that GitHub PRs don't surface at all.

git-sfs tracks only plain relative symlinks. A PR diff shows exactly which files were added, removed, or renamed - the same way any other file change looks in Git. Reviewers can approve or reject dataset changes with full context, and there are no sidecar files or hidden branches to reconcile.

git-sfs has no pipelines, no Python, no manifests, no committed lock files. The Git tree is the file list. The cache is a plain directory. The remote is whatever rclone can reach.

Concurrency and Partial Pulls

Large dataset workflows often mean hundreds of files if not millions. git-sfs runs add, push, and pull with a configurable worker pool:

# .git-sfs/config.toml
[settings]
n_jobs = 8

And partial pulls let teams share a repo where different machines only materialize what they actually use:

git-sfs pull data/train/         # only training split
git-sfs pull data/checkpoints/   # only model weights

Source

The project is open source under MIT: github.com/Red-Eyed/git-sfs

Feedback and issues welcome. If you're managing large files in Git and the LFS server tax is getting old, give it a try.

git-lrc and the Rise of AI Code Review Anxiety git-lrc and the Rise of AI Code Review Anxiety

Wed, 13 May 2026 06:17:09 +0000

git-lrc and the Rise of AI Code Review Anxiety

AI coding tools have fundamentally changed software development.

Developers can now generate entire functions, APIs, and architectures in minutes using tools like Copilot, Cursor, Claude Code, and GPT-powered agents. Software velocity has accelerated dramatically. But alongside this acceleration, a quieter problem has emerged:

Developers are increasingly shipping code they did not fully read, verify, or understand.

That is the exact engineering tension that git-lrc attempts to solve.

What is git-lrc?

git-lrc is an AI-powered pre-commit review system built by Hexmos. Instead of reviewing code only after a pull request is opened, git-lrc inserts an AI review layer directly into the Git workflow before commits are finalized.

In simple terms, it acts like a verification checkpoint between AI-generated code and permanent repository history.

The workflow is intentionally minimal:

git add .
git lrc review
git commit -m "message"

Rather than building another large dashboard-based review platform, git-lrc stays close to existing developer behavior. It integrates directly into Git, which makes adoption feel lightweight instead of disruptive.

That design decision is important.

Most developers do not want another complex AI platform. They want small tools that fit naturally into workflows they already trust.

The Real Problem Is Not AI Code Generation

The industry often frames AI-assisted development around productivity.

“How much faster can developers write code?”

But that framing misses the deeper issue.

The bottleneck is no longer code generation.

The bottleneck is comprehension.

Modern AI tools can generate code faster than humans can carefully inspect it. This creates a dangerous asymmetry:

code output increases,
understanding decreases,
and review quality slowly collapses.

Developers are beginning to experience what could be called review debt — a growing accumulation of code that nobody deeply examined.

This is where git-lrc becomes interesting.

The tool is not primarily about generating more software. It is about slowing developers down at the right moment.

Why Pre-Commit Review Matters

Traditional review systems usually operate:

during pull requests,
inside CI pipelines,
or after code has already entered repository history.

git-lrc changes the timing.

It reviews staged diffs before commit.

That small workflow shift has large implications.

When reviews happen before commit:

context is still fresh,
developers still remember intent,
mistakes are easier to correct,
and risky code is prevented from spreading downstream.

This “review-before-history” model feels increasingly relevant in the age of AI-assisted engineering.

Because once AI-generated code enters a repository, it rapidly becomes normalized. Future developers inherit it, build on top of it, and often trust it simply because it already exists.

Preventing low-confidence code from entering history may become one of the defining engineering disciplines of the AI era.

Features That Stand Out

1. AI-Powered Diff Reviews

git-lrc reviews staged changes before commit and attempts to identify:

logic regressions,
suspicious behavior,
risky cloud operations,
accidental credential leaks,
and other potentially dangerous modifications.

The goal is not perfect detection.

The goal is introducing friction before risky code becomes permanent.

2. Git-Native Design

One of the strongest aspects of the tool is its simplicity.

The workflow remains extremely close to standard Git usage. Developers are not forced into:

external dashboards,
complicated configuration layers,
or enterprise-heavy review systems.

That minimalism matters because developer tools succeed when they reduce cognitive overhead instead of increasing it.

An interesting aspect of git-lrc’s philosophy is that developers can:

approve,
skip,
or manually vouch for code.

But those actions remain visible.

This creates an engineering culture centered around accountability rather than passive trust in AI systems.

In a world increasingly obsessed with autonomous agents, this design philosophy feels unusually grounded.

git-lrc is essentially arguing that:

humans still need to understand what they deploy.

That sounds obvious, but modern AI tooling trends often move in the opposite direction.

The Emerging Fear Beneath AI Development

There is a growing anxiety across software engineering that few people openly discuss.

Developers increasingly wonder:

How much of modern codebases are truly understood?
How many AI-generated abstractions are entering production unchecked?
What happens when teams optimize entirely for velocity?

The danger is not necessarily malicious AI.

The danger is gradual detachment between developers and the systems they maintain.

Software engineering historically depended on comprehension:

reading code,
understanding architecture,
tracing logic,
reasoning about systems.

AI-assisted workflows risk weakening those habits if organizations prioritize output alone.

git-lrc appears to emerge directly from this tension.

It is less a productivity tool and more a defensive mechanism against cognitive drift inside modern engineering teams.

Tradeoffs and Limitations

Like any pre-commit system, git-lrc introduces tradeoffs.

Potential downsides include:

additional review friction before commits,
possible false positives,
reliance on external AI APIs,
and the temptation for developers to bypass the review process entirely.

The success of tools like this will depend on balancing:

review quality,
developer trust,
and workflow speed.

Too much friction and developers disable the hook.
Too little scrutiny and the review loses meaning.

That balance will define the future of AI review tooling.

A Shift in Engineering Philosophy

The most interesting part of git-lrc may not be the software itself.

It may be what the tool represents.

For years, engineering culture optimized for:

automation,
acceleration,
and abstraction.

Now a countertrend is beginning to appear:

verification,
traceability,
and comprehension.

The industry is slowly realizing that generating software faster is not enough if developers no longer understand the systems they are deploying.

git-lrc sits directly inside that transition.

And that is why the tool feels important beyond its feature set.

Final Thoughts

The AI coding revolution is not just changing how software is written.

It is changing the relationship developers have with understanding itself.

Tools like git-lrc suggest that the next stage of AI-assisted engineering may not focus purely on generation.

Instead, the future may revolve around a harder question:

How do we preserve human comprehension in an era of machine-accelerated software development?

That question extends far beyond a single Git tool.

But git-lrc is one of the first products attempting to confront it directly.

Please commit your changes or stash them before you merge. aborting

Mon, 11 May 2026 08:08:35 +0000

"Please commit your changes or stash them before you merge. Aborting" error occurs when trying to merge branches in Git and the current branch has uncommitted changes. To resolve this issue, either commit the changes or stash them using the Git stash command. This article will discuss the cause of the error and provide instructions on how to resolve it.

What is the problem?
How to solve this problem?
1. Commit the changes
2. Stash the changes
Conclusion
Reference

1. What is the problem? #

The "Please commit your changes or stash them before you merge. Aborting" error's message appears when attempting to merge branches in Git and the current branch has uncommitted changes.

In the below example, I've made a change in a file in feature-branch branch and trying to merge it into master branch without committing the change.


$ git checkout feature-branch
$ echo "new changes" >> file.txt
$ git checkout master
$ git merge feature-branch
error: Your local changes to the following files would be overwritten by merge:
file.txt
Please, commit your changes or stash them before you merge.
Aborting

As you can see, you could reproduce the same error by following these steps:

Checkout a branch where you have made changes to a file.
Switch to another branch without committing or stashing the changes.
Attempt to merge the first branch into the second branch.

This error can occur in various scenarios and may be encountered by developers while working with Git.

2. How to solve this problem? #

You must have realized how to do it by now. The message error already tell you what to do, committing the changes or stashing the changes. Let's me guide you to each solution step-by-step.

1. Commit the changes

The simplest solution to this error is to commit the changes in the current branch before attempting to merge with another branch. This will ensure that the changes are saved and can be easily retrieved if needed.

Check the status of the current branch to see the changes that have been made:
Add the changes to the stage:
Commit the changes:
Switch to the branch you want to merge into:
Merge the branch with the changes:

2. Stash the changes

Another solution to this error is to stash the changes in the current branch before attempting to merge with another branch. Stashing allows you to save the changes without committing them, so they can be retrieved later if needed.

Check the status of the current branch to see the changes that have been made:
Stash the changes:
Switch to the branch you want to merge into:
Merge the branch with the changes:
Retrieve the stashed changes:

Caution When stashing changes, it is important to remember that the stash is not permanent and may be lost if not reapplied or saved to a branch. It is recommended to regularly save stashes to a branch or reapply them to ensure the changes are not lost.

Both solutions ensure that the changes are saved and can be retrieved if needed, while also allowing the merge to proceed without interruption.

3. Conclusion#

In this article, we've discussed the error "Please commit your changes or stash them before you merge. Aborting" and its solutions of committing or stashing changes in the current branch before merging. Both solutions ensure changes are saved and retrievable while allowing the merge to proceed. If you have any questions or comments, feel free to leave them below. Have a nice day!

4. Reference#

For further information, please visit:

Git stash: https://git-scm.com/docs/git-stash
Git commit: https://www.atlassian.com/git/tutorials/saving-changes/git-commit
Git merge: https://www.atlassian.com/git/tutorials/using-branches/git-merge
Understanding the Git Workflow: https://guides.github.com/introduction/flow/

Nowadays, LLM is based and major for me

Mon, 11 May 2026 04:56:55 +0000

https://github.com/topstar-ai/OpenLLM
https://bentoml.com

Run any open-source LLMs, such as DeepSeek and Llama, as OpenAI compatible API endpoint in the cloud.

[Fixed] Fatal: could not read from remote repository.

Thu, 07 May 2026 07:14:16 +0000

The "Fatal: could not read from remote repository" error occurs when a Git client is unable to access a remote repository. This error can happen for several reasons, such as a network connection issue, incorrect repository URL, or insufficient permissions. To solve this problem, you can try a number of methods such as checking your network connection, verifying the repository URL, and ensuring you have the proper permissions to access the repository. In this article, we'll provide detailed solutions to help you resolve it.

What is the problem?
How to solve this problem?
Conclusion
Reference

1. What is the problem? #

a. Define the problem

The "Fatal: could not read from remote repository" error is a common issue faced by Git users when they try to access a remote repository. This error message usually appears in the terminal or command line interface when the Git client is unable to establish a connection with the remote repository. The error message typically appears as follows:

$ git clone https://github.com/user/repo.git
Cloning into 'repo'...
fatal: unable to access 'https://github.com/user/repo.git/': Could not read from remote repository.

b. Why is it occur?

This error can occur for several reasons, some of which are listed below:

Incorrect repository URL: If the repository URL is incorrect or invalid, the Git client will not be able to connect to the remote repository and the error message will appear.
Network connection issue: If there is a problem with your network connection, the Git client will not be able to establish a connection with the remote repository and the error message will appear.
Insufficient permissions: If the Git client does not have the necessary permissions to access the remote repository, the error message will appear.
Firewall or proxy restrictions: If there is a firewall or proxy restriction in place, the Git client may not be able to establish a connection with the remote repository and the error message will appear.

Caution Some of these reasons can be easily resolved, others may require a more technical understanding of Git and network configurations. If you are unable to resolve the error on your own, it may be necessary to consult with a more experienced Git user or your system administrator.

c. Reproduce the error

To reproduce the error, try cloning a remote repository using the Git client. If the error message appears, then it indicates that there is a problem with accessing the remote repository. For example, if you try to clone a repository using the following command:

$ git clone https://github.com/user/repo.git

And the error message appears, which means that there is a problem with accessing the remote repository.

Another way to reproduce the error is by trying to push changes to a remote repository using the Git client. If the error message appears, it means that there is a problem with accessing the remote repository. For example, the error message will appear if you try to push changes to a remote repository using the following command:

$ git push origin master

For general cases, understanding the reasons behind this error message is crucial in order to troubleshoot and solve the problem.

2. How to solve this problem? #

Caution Before making any changes to your Git configuration, it is important to backup your existing settings and to thoroughly understand the implications of each solution.

Here are some methods that you can try to resolve the problem:

Checking the URL: Ensure that the URL of the remote repository is correct. If you are using an HTTPS URL, make sure that it is typed correctly and is accessible from your network. You can also try using an SSH URL instead. To do this, use the following command:

$ git clone *Emails are not allowed*:user/repo.git

Configuring proxy: If your network requires a proxy to access the Internet, configure Git to use the proxy by setting the 'http_proxy' and 'https_proxy' environment variables. You can do this by adding the following lines to your Git configuration file located at '~/.gitconfig':

[http]
  proxy = http://proxy.example.com:8080
[https]
  proxy = https://proxy.example.com:8080

Checking SSH keys: If you are using an SSH URL to clone the repository, make sure that the SSH key being used is correctly set up and associated with your GitHub account. You can check this by running the following command:

$ ssh -T *Emails are not allowed"

Using Git protocol version 2: If you are using a version of Git prior to 2.0, you may encounter the "Fatal: could not read from remote repository" error. To resolve this, upgrade to the latest version of Git or use the '-v' option to specify version 2 of the Git protocol.

$ git clone -v --branch  [branch] [repo]

Disabling firewalls: Firewall restrictions may prevent Git from accessing the remote repository. To resolve this, you can either temporarily disable the firewall or allow Git through the firewall.

Note It is recommended to try each solution in the order presented, as some solutions may not be applicable or necessary in every case. Additionally, some solutions may require administrative privileges and may need to be performed on a server or by your system administrator.

3. Conclusion#

In this article, we discussed the "Fatal: could not read from remote repository" error and its causes. The error message occurs when a Git client is unable to access a remote repository and can be caused by several factors such as an incorrect repository URL, network connection issues, insufficient permissions, or firewall or proxy restrictions. We also provided several methods for resolving the error, including verifying the repository URL, checking the network connection, ensuring proper permissions, and checking for firewall or proxy restrictions.

If you have any questions or comments, feel free to leave them below. Have a nice day!

4. Reference#

For further information, please visit:

"Git clone: fatal: Could not read from remote repository" - Git Documentation: https://git-scm.com/docs/git-clone#git-clone---mirror
"Git - Cloning a Repository": https://git-scm.com/docs/git-clone
"GitLab - Importing a Repository": https://docs.gitlab.com/ee/user/project/repository/importing.html

Git Command

Sun, 03 May 2026 07:05:31 +0000

The Clean All (discard all changes)

git clean -fd

How do you move a commit to the staging area in git?

git reset --soft HEAD~1

Pushing empty commits to remote

git commit --allow-empty -m "Trigger Build"

History

git log --graph --color --decorate --oneline --all

gitk --all

Git to discard uncommitted changes in your working directory

git restore .

Moves the last commit back to the staging area (index), keeping all changes.

git reset --soft HEAD~

Moves the last commit back to the staging area (index), Discard all changes.

git reset --hard HEAD~

Deletes a local branch named branch_name.

git branch -d branch_name

Force Delete a Branch (If Not Merged):

git branch -D branch_name

Delete a Remote Branch:

git push origin --delete branch_name

List both local & remote branches:

git branch -a

Prunes (removes) local references to remote branches that no longer exist on the remote.

git fetch --prune

Quickly Switch to the Previous Branch

git checkout -

Show a Visual Branch Tree

git log --oneline --graph --all

Search Commit Messages

git log --grep="bugfix"

Configures Git to use Windows' built-in SSL/TLS (Schannel) instead of OpenSSL

git config --global https.sslBackend schannel

Trigger the CI/CD pipeline with a blank commit

git commit --allow-empty -m 'Empty commit'

visualizing Git history

gitk

How do you move a commit to the staging area in git?

git reset --soft HEAD~1

Git to discard uncommitted changes in your working directory

git restore .

source:- link

The Renaissance of Git Worktrees

Thu, 30 Apr 2026 18:08:50 +0000

Git worktrees are not new. They were introduced back in 2015 as part of Git version 2.5. For years, they stayed mostly under the radar, used by a small group of developers who understood their value.

Now they are suddenly everywhere.

In 2025 and 2026, worktrees have seen a strong resurgence. The reason is the way we write code is changing. With the rise of agent driven development and parallel workflows, worktrees have become a practical necessity.

What are Git worktrees

Normally, if you are inside one cloned repository and you switch branches, your whole working directory changes with it. That becomes annoying in situations like these:

You are working on a feature, and suddenly need to fix a production bug on another branch
You want to review a pull request locally without disturbing your current work
You want to compare two branches side by side
You need one directory for development and another for running tests or a local build on a different branch

Without worktrees, many developers solve this by cloning the same repository multiple times. That works, but it wastes disk space, duplicates setup, and creates extra maintenance. Worktrees give you multiple folders while still using the same underlying repository.

How it works

You keep your normal repository folder, then create extra folders attached to it. Each folder can be on a different branch.

my-app/                 # main worktree
my-app-feature-login/   # linked worktree
my-app-hotfix/          # linked worktree

Each one is a real working directory, so you can open it in your editor, run builds there, and commit from there. Git keeps metadata so it knows all these directories belong to the same repository.

The main command is:

git worktree add <path>

For example, start in your main project:

git branch

* main

Now create a new worktree for a feature:

git worktree add ../app-feature-login -b feature/login

What happens here:

a new folder ../app-feature-login is created
a new branch feature/login is created
that branch is checked out in the new folder

Now you have:

app/                  # main branch
app-feature-login/    # feature/login branch

You can open both in your editor and have your coding agents work simultaneously without interrupting each other.

How to Make Conventional Commits a Lasting Habit?

Thu, 30 Apr 2026 15:47:59 +0000

Conventional commits sound great in theory: structured, readable commit messages that make history tracking easier. But let's be honest—most of us try them for a few days and then fall back into our old habits. Why? Because it’s tedious to remember the exact syntax, and we often don’t have the patience to write proper commit messages when we’re in the zone.

The Problem: Conventional Commits Fade Away Quickly

If you've ever attempted to enforce conventional commits in your projects, you might have noticed this pattern:

Day 1: You're excited and commit with messages like feat: add authentication module or fix: resolve login bug.
Day 3: You start forgetting the exact format and write something like feat(auth): added stuff.
Day 7: You're back to fix bug or wip, and conventional commits are a thing of the past.

It’s not that you don’t see the value—it’s just hard to stay consistent without frictionless tooling. That’s where convcommit comes in.

Meet Convcommit: Your Memory Booster for Commit Messages

convcommit is a simple but powerful CLI tool that ensures you never fall back into bad commit habits. It does a few things:

✅ Guides you through commit message selection – No need to memorize commit types or scopes.

✅ Stores and suggests your previous messages – If you’ve used a message before, you can quickly reuse it.

✅ Works with git add . and git push seamlessly – Keeping your workflow fast and efficient.

How It Works

Using convcommit is straightforward:

Install it (if you haven’t already):
```
mush install convcommit
```
Run it whenever you commit:
```
convcommit -a -p
```
Select the commit type, scope (if any), and message from suggestions or enter a new one.

That’s it! No more second-guessing your commit messages or breaking your commit history structure.

Why You Should Start Using It Today

Develop muscle memory: The more you use it, the more natural conventional commits become.
Maintain a clean commit history: Future-you (and your teammates) will thank you.
Boost your personal branding: Writing clean commits is a sign of professionalism in open-source projects.

Try It Now and Make Your Commits Count!

You can check out convcommit on GitHub, give it a star ⭐, and start using it today:

GitHub Repo

Let me know what you think, and if you have ideas for improvements, PRs are always welcome! Happy committing!

GitHub Suspended Me. Turns Out, That Was Fine.

Mon, 27 Apr 2026 16:54:04 +0000

Okay so I've been putting off writing this post for weeks because honestly I wasn't sure how much I wanted to share. But enough people have asked what happened with Ultimate Media Downloader that I figure I owe everyone an explanation. Fair warning: this is long. Make a coffee.

Late March 2026. Everything was normal. I was pushing updates, answering issues, doing the usual open-source maintainer thing. Nothing felt off. I had notifications from GitHub, I was working on a fix for a bug that had been annoying me for days, and life was... fine, you know? Boring good. The kind of good you don't appreciate until it's gone.

Then GitHub suspended my account.

Day One: The Screen That Broke My Brain

I'm not going to pretend I handled it gracefully. I did not.

I opened GitHub to push a commit and got the suspension screen. My brain kind of just... stopped for a second. I reread it three times thinking I was somehow misreading it. I wasn't.

The reason they gave was vague. Something about policy violations and suspicious activity. I genuinely had no idea what I'd done. I mean — I host a media downloader. I've always known that sits in a gray area. But I wasn't the first person to do this, and there are way bigger projects doing the exact same thing still sitting on GitHub right now, so I figured I'd just... appeal it and it'd get sorted.

Reader, it did not get sorted quickly.

Shouting Into the GitHub Support Void

Have you ever submitted an appeal to a large tech platform? It's a specific kind of miserable. You write this really thoughtful, detailed explanation. You cite examples. You reference other projects. You basically build a legal case for why your account should be reinstated. And then you get back an email that reads like it was written by someone who definitely did not read your email.

That was my week two.

I sent multiple follow-ups. I explained that the software is a tool and that tools don't have intent. I pointed out YouTube-DL, which does functionally the same thing and had its own GitHub drama a few years back. Nothing landed. Or if it did, nobody told me.

What made it worse — and this is the part that kept me up at night — is that I had users. Real people relying on auto-updates that pulled from GitHub releases. My version checker hit the GitHub API. Everything was tangled up with my account. And I was locked out.

By about day ten I stopped waiting and started planning.

The Backwards Move That Actually Worked

I'm skipping over some of the specifics here because honestly they're boring and a bit embarrassing. But the short version is: I managed to get temporary access to the repo through some recovery options I'd forgotten I'd set up years ago.

My first instinct when I got in was to back everything up. And then I made what felt like a weird call at the time: I made the repository private.

I know that sounds backwards. "Your project is already invisible because your account is suspended, why would you make it more invisible?" But my thinking was — if GitHub sees a popular public repo suddenly go private, maybe they interpret that as me taking security concerns seriously rather than being a bad actor. It was a gamble.

Turns out it kind of worked? I started getting slightly less robotic responses from their support team. Something shifted. I don't know exactly what, and I'm not going to pretend I do.

Back In, But Not Really Welcome

They reinstated the account. With conditions attached. Basically: the main repo for Ultimate Media Downloader couldn't stay as-is. Too "potentially problematic." That was their phrase, not mine.

So I was back. But it didn't feel like a win. It felt like being let back into a party where the host is clearly not happy you're there. You're standing by the snack table and every few minutes someone glances at you and you're like — yeah I know, I know.

That was the moment I actually started taking Codeberg seriously.

Fine. Let's Try This Codeberg Thing.

I'd known Codeberg existed for a while. I'd seen it mentioned in open-source forums and had vaguely filed it away as "GitHub but smaller and European." Never felt urgent enough to actually explore.

Now it felt urgent.

I spent a day on the platform just clicking around. And the first thing I noticed was how — I don't know how to say this without sounding cheesy — how genuine it felt? There's no AI assistant trying to summarize your commits. No featured marketplace pushing you to buy things. No weird enterprise upsell banners. It's just a git hosting platform run by a non-profit that actually believes in what it's doing.

That shouldn't be a revelation. But after the GitHub experience it kind of was.

The other thing I noticed: nobody there was going to suspend my account for hosting a media tool. Because they actually care about software freedom. Not performatively — actually.

By end of week four I'd made up my mind.

The Actual Migration

This part is less dramatic than the rest of the story. Migrations are mostly just tedious, not traumatic.

I updated the README. Changed the clone URLs. Updated the version checker endpoint from GitHub's API to Codeberg's. Went through the contributing docs, the code of conduct, the issue templates — every file that had a github.com link in it. Found more than I expected. One of them was buried in a comment inside a Python file that I'd written like two years ago and completely forgot about. That took a minute.

Total time: maybe a day and a half, spread over two days because I kept getting distracted.

The harder part was more psychological. I'd been on GitHub for years. All my institutional memory of "where things live" pointed there. Switching platforms meant rewriting some mental muscle memory, which sounds small but isn't.

But once it was done? I felt weirdly relieved.

Where We're At Now

It's late April. The project lives on Codeberg now. Everything works. Updates go out, the version checker works, people are downloading things just fine.

The Codeberg community is smaller. That's real. Fewer people stumble across your project because there's no algorithm surfacing it. But the people who do find it seem more... intentional? Like they were looking for something specific rather than just scrolling. I've had better issue reports in the last few weeks than I used to get in a month.

I still have my GitHub account. I'm using it mostly to mirror things over there, just so people who bookmarked old URLs don't hit dead ends. But I'm not building anything like that there anymore.

But still using the githb to showcase my previous successful project and more. because i don't want to sart over all of it again.

The Actual Takeaway

I don't want to wrap this up with some neat lesson because the experience wasn't neat.

It was stressful. I was anxious for basically a month straight. I sent emails to GitHub support that I now find slightly embarrassing in retrospect. I lost sleep. My project went dark for a stretch of time and I couldn't even tell users why because I didn't fully understand why myself.

But — and I mean this — I wouldn't have moved to Codeberg if it hadn't happened. I was too comfortable. Sometimes that's what it takes.

If you're one of the users who noticed things were broken and didn't get an explanation at the time: I'm sorry. That sucked and you deserved better communication from me. I was in reactive mode and honestly just trying to keep the thing alive.

It's alive. It's on Codeberg. Come find it there.

One more thing

I still have like four documentation files somewhere that probably have a github.com URL hiding in them. I'll find them eventually. If you spot one before I do, open an issue. On Codeberg, obviously.

— NK2552003

Writing from my home office which is definitely a real office and not just my bed with a laptop

Codeberg > UMD
Github

ArgoCD Guide: GitOps Continuous Delivery for Kubernetes

Thu, 23 Apr 2026 12:47:43 +0000

ArgoCD has become the de facto standard for GitOps-based continuous delivery in Kubernetes. If you are running production workloads on Kubernetes and still deploying with raw kubectl apply or untracked Helm releases, ArgoCD solves a class of problems you may not even know you have yet. This guide covers everything from core concepts to production-grade configuration.

The Problem ArgoCD Solves

Traditional CI/CD pushes deployments into a cluster. A CI system runs tests, builds an image, and then executes kubectl apply or helm upgrade against the cluster. This model has several structural problems:

Drift goes undetected. Someone applies a hotfix directly to the cluster. Now your Git repository no longer reflects reality, and nobody knows it.
No single source of truth. The cluster state is authoritative, not Git. Your desired state and actual state can diverge silently.
Rollback is painful. Rolling back a bad deployment means re-running old CI pipelines or manually reversing changes, neither of which is fast.
Multi-cluster management compounds the problem. Each cluster becomes a snowflake with its own history of undocumented changes.

GitOps inverts this model. Git is the source of truth. The cluster pulls its desired state from Git and continuously reconciles toward it. ArgoCD is the most mature GitOps operator for Kubernetes, implementing this pull-based model with a production-ready feature set.

How ArgoCD Works: Core Architecture

ArgoCD runs as a set of controllers inside your Kubernetes cluster. The core components are:

Application Controller — Watches both the Git repository and the live cluster state. Computes the diff and drives reconciliation.
API Server — Exposes the gRPC/REST API consumed by the CLI, UI, and external systems.
Repository Server — Generates Kubernetes manifests from source (Helm, Kustomize, plain YAML, Jsonnet).
Redis — Caches cluster state and repository data to reduce API server load.
Dex (optional) — Provides OIDC authentication for SSO integration.

The fundamental unit in ArgoCD is an Application — a CRD that maps a source (a path in a Git repo at a specific revision) to a destination (a namespace in a cluster). ArgoCD continuously compares the desired state from Git with the live state in the cluster and reports on the sync status.

Sync Status vs Health Status

Two orthogonal concepts you need to understand from day one:

Sync Status — Does the live state match what Git says it should be? Values: Synced, OutOfSync, Unknown.
Health Status — Is the application actually working? Values: Healthy, Progressing, Degraded, Suspended, Missing, Unknown.

An application can be Synced but Degraded — the manifests were applied correctly, but a pod is crash-looping. Conversely, it can be OutOfSync but Healthy — someone applied a change directly to the cluster outside of Git.

Installing ArgoCD

The official installation method uses a single manifest. For production, always pin to a specific version:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.11.0/manifests/install.yaml

This deploys ArgoCD in the argocd namespace with full cluster-admin access. For a production HA setup, use the manifests/ha/install.yaml variant, which deploys multiple replicas of the API server and application controller.

Accessing the UI and CLI

The initial admin password is auto-generated and stored in a secret:

argocd admin initial-password -n argocd

For local access, port-forward the API server:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Then log in via the CLI:

argocd login localhost:8080 --username admin --password <password> --insecure

For production, expose the ArgoCD server via an Ingress or LoadBalancer with a proper TLS certificate. If you’re using NGINX Ingress Controller:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server-ingress
  namespace: argocd
  annotations:
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  ingressClassName: nginx
  rules:
  - host: argocd.yourdomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argocd-server
            port:
              number: 443

Defining Your First Application

Applications can be created via the UI, the CLI, or declaratively with a YAML manifest. The declarative approach is the recommended one — it means your ArgoCD configuration itself is in Git:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/your-app
    targetRevision: HEAD
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Key fields to understand:

targetRevision — Can be a branch name, tag, or commit SHA. For production, pin to a tag rather than HEAD.
path — The directory within the repo containing your Kubernetes manifests.
automated.prune — Automatically delete resources that are no longer in Git. Required for true GitOps but use carefully — it will delete things.
automated.selfHeal — Automatically revert manual changes made directly to the cluster. This is what enforces Git as the single source of truth.

Helm Integration

ArgoCD has native Helm support. It can deploy Helm charts directly from chart repositories or from your Git repository. You can override values per environment:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus-stack
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://prometheus-community.github.io/helm-charts
    chart: kube-prometheus-stack
    targetRevision: 58.4.0
    helm:
      releaseName: prometheus-stack
      valuesObject:
        grafana:
          adminPassword: "${GRAFANA_PASSWORD}"
        prometheus:
          prometheusSpec:
            retention: 30d
            storageSpec:
              volumeClaimTemplate:
                spec:
                  storageClassName: fast-ssd
                  resources:
                    requests:
                      storage: 50Gi
  destination:
    server: https://kubernetes.default.svc
    namespace: observability

One important nuance: ArgoCD renders Helm charts server-side using its own templating engine, not helm install. This means Helm hooks (pre-install, post-upgrade, etc.) are supported, but the release is not tracked in Helm’s release history. Running helm list will not show ArgoCD-managed releases unless you configure ArgoCD to use the Helm secrets backend.

Projects: Multi-Tenancy and Access Control

ArgoCD Projects provide multi-tenancy within a single ArgoCD instance. They let you restrict which source repositories, destination clusters, and namespaces a team can deploy to. Every Application belongs to a Project.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: platform-team
  namespace: argocd
spec:
  description: Platform team applications
  sourceRepos:
  - 'https://github.com/your-org/*'
  destinations:
  - namespace: 'platform-*'
    server: https://kubernetes.default.svc
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  namespaceResourceBlacklist:
  - group: ''
    kind: ResourceQuota

Projects are where you define the boundaries of what each team can do. The default project has no restrictions — never use it for production workloads. Create dedicated projects per team or per environment.

RBAC Configuration

ArgoCD has its own RBAC system layered on top of Kubernetes RBAC. It is configured via the argocd-rbac-cm ConfigMap. Roles are defined per project or globally:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.default: role:readonly
  policy.csv: |
    # Platform team has full access to platform-team project
    p, role:platform-admin, applications, *, platform-team/*, allow
    p, role:platform-admin, projects, get, platform-team, allow
    p, role:platform-admin, repositories, *, *, allow

    # Dev team can sync but not delete
    p, role:developer, applications, get, */*, allow
    p, role:developer, applications, sync, */*, allow
    p, role:developer, applications, action/*, */*, allow

    # Bind SSO groups to roles
    g, your-org:platform-team, role:platform-admin
    g, your-org:developers, role:developer

The policy.default: role:readonly ensures that any authenticated user who has no explicit role assignment gets read-only access — a safe default for production.

Multi-Cluster Management

ArgoCD can manage multiple Kubernetes clusters from a single control plane. Register external clusters with the CLI:

# First, ensure the target cluster context is in your kubeconfig
argocd cluster add production-eu-west --name production-eu-west

# Verify registration
argocd cluster list

ArgoCD will create a ServiceAccount in the target cluster and store its credentials as a Kubernetes secret in the ArgoCD namespace. Applications can then target this cluster by name in their destination.server field.

For large-scale multi-cluster setups, consider the App of Apps pattern or ApplicationSets. ApplicationSets are a controller that generates Applications dynamically based on generators — cluster lists, Git directory structures, or matrix combinations:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-addons
  namespace: argocd
spec:
  generators:
  - clusters:
      selector:
        matchLabels:
          environment: production
  template:
    metadata:
      name: '{{name}}-addons'
    spec:
      project: platform
      source:
        repoURL: https://github.com/your-org/cluster-addons
        targetRevision: HEAD
        path: 'addons/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: kube-system

This single ApplicationSet deploys the appropriate addons to every cluster labeled environment: production, using each cluster’s region label to select the correct path in the repository.

Sync Strategies and Waves

When deploying complex applications with dependencies between resources, you need to control the order of deployment. ArgoCD provides two mechanisms:

Sync Phases

Resources are deployed in three phases: PreSync, Sync, and PostSync. Use Sync Hooks for resources that must complete before the main sync proceeds (database migrations, certificate issuance, etc.):

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
      - name: migrate
        image: your-app:v1.2.3
        command: ["./migrate.sh"]
      restartPolicy: Never

Sync Waves

Within the Sync phase, waves control ordering. Resources with a lower wave number are applied and must become healthy before resources with higher wave numbers are applied:

# Applied first
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"

# Applied after wave 1 is healthy
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "2"

Notifications and Alerting

ArgoCD Notifications is a standalone controller that sends alerts when Application state changes. It supports Slack, PagerDuty, GitHub commit status, email, and a dozen other providers. Configure it via the argocd-notifications-cm ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  service.slack: |
    token: $slack-token
  template.app-sync-failed: |
    slack:
      attachments: |
        [{
          "title": "{{.app.metadata.name}}",
          "color": "#E96D76",
          "fields": [{
            "title": "Sync Status",
            "value": "{{.app.status.sync.status}}",
            "short": true
          },{
            "title": "Message",
            "value": "{{range .app.status.conditions}}{{.message}}{{end}}",
            "short": false
          }]
        }]
  trigger.on-sync-failed: |
    - when: app.status.sync.status == 'Unknown'
      send: [app-sync-failed]
    - when: app.status.operationState.phase in ['Error', 'Failed']
      send: [app-sync-failed]

Secret Management with ArgoCD

ArgoCD intentionally has no secret management built in — storing secrets in Git as plain text is never acceptable. The common patterns are:

Sealed Secrets (Bitnami) — Encrypts secrets with a cluster-specific key. The encrypted secret can be committed to Git; only the cluster can decrypt it.
External Secrets Operator — Syncs secrets from Vault, AWS Secrets Manager, GCP Secret Manager, etc. into Kubernetes secrets. The ArgoCD Application manages the ExternalSecret CRD, not the actual secret value.
argocd-vault-plugin — A plugin that replaces placeholder values in manifests with secrets retrieved from Vault at sync time.

The External Secrets Operator approach is the most flexible for teams already using a centralized secrets backend. The Application in ArgoCD deploys ExternalSecret objects, which the ESO controller resolves at runtime without ever touching Git.

Production Best Practices

Run ArgoCD in HA mode. Use manifests/ha/install.yaml with 3 replicas of the API server and multiple application controller shards for large clusters (100+ applications).
Pin image versions. Never use latest for the ArgoCD image itself. Pin to a specific version and upgrade deliberately.
Use the App of Apps pattern for bootstrapping. A single root Application deploys all other Applications. This makes cluster bootstrapping idempotent and reproducible.
Separate ArgoCD config from application config. Store ArgoCD Application manifests in a dedicated gitops repository, separate from application source code.
Enable resource tracking via annotations. Use application.resourceTrackingMethod: annotation in argocd-cm instead of the default label-based tracking, which can conflict with Helm’s own labels.
Set resource limits on ArgoCD controllers. Application controller CPU and memory scale with the number of resources tracked. Monitor and tune accordingly.
Restrict auto-sync in production. Consider requiring manual sync approval for production environments even when using GitOps — or at minimum require a PR approval gate before changes reach the target branch.

ArgoCD vs Flux

Flux v2 is the other major GitOps operator. Both are CNCF projects. The main differences in practice:

Feature	ArgoCD	Flux v2
UI	Built-in web UI	No official UI (use Weave GitOps)
Multi-cluster	Single control plane manages many clusters	Agent per cluster, pull model
ApplicationSets	Native	Kustomization + HelmRelease
Secret management	Plugin-based	SOPS native integration
Learning curve	Steeper (more concepts)	Lower (Kubernetes-native CRDs)
CNCF status	Graduated	Graduated

ArgoCD wins when you need the UI, multi-cluster management from a central plane, or have a large operations team that benefits from the visual application topology view. Flux wins when you want a simpler, purely Kubernetes-native approa

GitWand - A complete workflow for GIT

Tue, 21 Apr 2026 21:13:19 +0000

Every Git client I've ever used treats merge conflicts the same way: show the markers, let the human figure it out. Even for the obvious ones — a lockfile where both branches bumped a version number, a config file where only one side changed a value, two branches that independently made the exact same edit. The tool knows it's a conflict. It just doesn't try to resolve it.

PhpStorm has a "magic wand" button that resolves trivial conflicts automatically. It's one of those features that, once you've used it, makes every other editor feel like it's missing a limb. I wanted that everywhere — not just in PhpStorm, not just with a specific language server. So I built the engine myself, as a standalone TypeScript library at the core of GitWand.

Why I built another Git client

Tue, 21 Apr 2026 21:13:15 +0000

There are already a dozen Git GUIs. GitKraken, Fork, Tower, Sourcetree, GitHub Desktop, Sublime Merge, GitButler. Most of them are good. Some of them are excellent. So when people ask why I spent the better part of a year building yet another one, I owe them a real answer.

The short version: every Git client I've used shows you merge conflicts and stops there. Even for the obvious ones.

The thing that kept bothering me

PhpStorm has a "magic wand" button in its merge editor. When you open a conflicted file, it scans every hunk and resolves the trivial ones automatically — the ones where only one side changed something, where both sides made the same edit, where the differences are just indentation. You're left with only the conflicts that genuinely need human judgment.

It's one of those features that, once you've used it, makes every other tool feel like it's missing a limb.

I've been using Git for a long time. I've resolved a lot of merge conflicts. And a huge portion of them — I'd estimate somewhere between 60% and 80% in a typical week — are completely trivial. A lockfile where two branches bumped the same dependency to different patch versions. A config file where only one branch touched a value. Two branches that independently made the exact same edit. None of these require a human decision. They're just noise.

Every Git client I know makes you resolve them manually anyway.

What I actually wanted

I wanted a Git client that understood the structure of a conflict, not just its existence.

Not an AI that guesses at resolution and might hallucinate the wrong answer. Something deterministic — a classifier that applies explicit rules, explains its reasoning, and never touches anything ambiguous. If it's not certain, it asks. If it is certain, it just fixes it.

I also wanted this to be available everywhere, not just inside a specific IDE. In the terminal (npx @gitwand/cli resolve). In CI (--ci flag, structured JSON output). As an MCP tool that AI agents like Claude can call. And in a native desktop app that doesn't cost $150MB of RAM just to show a diff.

That's GitWand.

The conflict resolution engine

The core of GitWand is a pattern registry — nine conflict types, evaluated in priority order, each with an explicit detection rule and a confidence score.

The patterns, from simplest to most complex:

The engine requires git merge --diff3 (or merge.conflictstyle diff3 in your config) to unlock the most powerful patterns. With the three-way base available, one_side_change is trivially detectable: if ours matches the ancestor but theirs doesn't, take theirs. Without the base, you can't tell who changed what.

Every resolution carries a composite confidence score — not a simple label, but a weighted formula across five dimensions: classification certainty, data risk, block size, file complexity, and base availability. Anything below "high" is left for you, with a full decision trace explaining what was detected and why.

✓ src/config.ts — 3/3 resolved
  L12 [one_side_change] certain — Only the incoming branch modified this block.
  L25 [same_change] certain — Both branches made the exact same edit.
  L41 [value_only_change] high — Scalar value updated on one side (version field).

The merge preview

One of my favorite features — and the one that gets the most surprised reactions from people seeing it for the first time — is the merge preview.

Before you merge any branch, GitWand simulates the outcome without touching your working tree. It uses git merge-base, git show, and git merge-file -p --diff3 to compute exactly what would happen, then shows you a per-file breakdown:

Auto-resolvable — the engine can handle it
Partial — some hunks need your attention
Manual — complex conflicts requiring human judgment
Add/delete — a file was added on one side, deleted on the other

The summary badge tells you at a glance: Clean merge, 100% auto-resolvable, or 3 conflicts to review.

This matters because the worst time to discover a gnarly conflict is after you've already run git merge and your working tree is in a half-merged state. The preview gives you that information before you commit to anything.

Format-aware resolvers

Plain-text conflict detection misses a lot. Two branches that both added a dependency to package.json will appear as an overlapping edit on the dependencies block — a false conflict, because the changes are semantically independent.

GitWand ships semantic resolvers for the file formats where this happens most often: JSON and JSONC (recursive key-by-key merge), Markdown (section-by-section merge by ATX heading), YAML, Vue single-file components, CSS/SCSS, TypeScript/JavaScript imports, and the major lockfile formats (npm, yarn, pnpm). For Cargo.toml. For Dockerfile. For .env.

The JSON resolver, as a quick example: it parses all three versions (ours, theirs, base), computes per-key diffs, and merges key by key. A key added on one side only → accept it. A key modified identically on both sides → keep it. A key modified differently on both sides → flag it as unresolvable and fall back to text. Nested objects are handled recursively.

The result is that a package.json where one branch added lodash and another added axios gets merged cleanly, even though the dependencies block was "touched" on both sides.

The CLI and the MCP server

The desktop app is the main interface, but the engine doesn't live only there.

npx @gitwand/cli resolve runs the same engine from the terminal. --dry-run previews without writing. --verbose shows the full decision trace per hunk. --ci returns structured JSON with confidence scores, decision traces, and a pendingHunks array for the conflicts the engine couldn't resolve.

That pendingHunks array is the bridge to the MCP server (@gitwand/mcp). An AI agent — Claude, Cursor, Windsurf — can call gitwand_resolve_conflicts, get back the trivially-resolved hunks plus the unresolved ones with full context, and then apply its own reasoning to the remainder via gitwand_apply_resolution. GitWand handles the deterministic part. The LLM handles the semantic reasoning. Neither tries to do the other's job.

What was harder than expected

A few things humbled me during this build.

Edge cases in JSON merging. The recursive key-by-key approach works well for most configs, but there are pathological cases — arrays of objects where identity is ambiguous, deeply nested structures where one side restructured the hierarchy. The resolver has to know when to give up and fall back to text, and getting that boundary right took more iteration than I expected.

The whitespace_only false positive problem. Whitespace differences that are semantically neutral in most languages (trailing spaces, mixed tabs/spaces) are semantically significant in Python. The resolver normalizes aggressively but has to be careful not to flatten indentation that carries meaning.

macOS Gatekeeper. GitWand isn't notarized yet (it's on the roadmap). First launch on macOS requires a right-click → Open workaround because Gatekeeper blocks unsigned apps. This creates unnecessary friction for new users and is near the top of the priority list.

Auto-update. The mechanism exists but had four silent bugs that were preventing it from ever triggering in practice. Fixing them went into v1.6.3 alongside the worktree and submodule work.

Where things stand

GitWand is at v1.6.2. It covers the full daily Git workflow — changes, history, branches, push/pull, cherry-pick, stash, interactive rebase, amend, PR review with inline comments and CI checks — plus the conflict resolution engine, the merge preview, the CLI, the MCP server, and a VS Code extension.

322 tests passing. MIT licensed. Available for macOS, Linux, and Windows.

The repo is at github.com/devlint/GitWand. If you want just the engine without the desktop app, npx @gitwand/cli resolve is the fastest way in.

And if you use git merge --diff3 (you should: git config --global merge.conflictstyle diff3), the engine will automatically use the three-way base for better classification.

Understanding Closures in Go

Mon, 23 Mar 2026 10:11:14 +0000

Hello, I'm Ganesh Kumar. I'm working on git-lrc: a Git hook for Checking AI generated code.AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

In my previous post, I explained how anonymous functions created and understand how it works.

In this article we will understand how closure.

What is closure

A closure is a function value that references variables from outside its body.

The function may access and assign to the referenced variables; in this sense the function is "bound" to the variables.

How closure is used?

Each time new value updates the sum variable.

Next time when we call the function, it will use the updated value of sum.

So, It remembers the value of sum.


package main

import "fmt"
func adder(x int) func(int) int {
    sum := 0
    return func(y int) int {
        sum += y
        return sum
    }
}


func main() {
   pos,neg := adder(0),adder(0)
   for i := 0; i < 10; i++ {
        fmt.Println(
            pos(i),
            neg(-i),
        )
    }

}

Output:

gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
0 0
1 -1
3 -3
6 -6
10 -10
15 -15
21 -21
28 -28
36 -36
45 -45

Fibonacci series

Here is the example of fibonacci series.
initially we are initializing a and b with 0 and 1.

then with each time calling the function it will return the return value of a.

and update the value of a and b.

So, hence creating a fibonacci series.

package main

import "fmt"

// fibonacci is a function that returns
// a function that returns an int.
func fibonacci() func() int {
    a, b := 0, 1
    return func() int {
        ret := a
        a, b = b, a+b
        return ret
    }
}

func main() {
    f := fibonacci()
    for i := 0; i < 10; i++ {
        fmt.Println(f())
    }
}

Output:

gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
0
1
1
2
3
5
8
13
21
34

Conclusion

In this article we understood how closure is used. closure is a function value that references variables from outside its body.

Check out: git-lrc
Any feedback or contributors are welcome! It’s online, open-source, and ready for anyone to use.
⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

git-lrc-intro-60s.mp4

Why

AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
Build a habit, ship better code. Regular review → fewer bugs → more robust code → better results in your team.
Why git? Git is universal. Every editor, every IDE, every AI…

View on GitHub

The New Minimum: What You Must Know About Code You Didn't Write?

Fri, 20 Mar 2026 02:22:13 +0000

Let's be honest. We don't read code anymore.

AI writes it. We skim it. We ship it. Maybe we glance at the diff in a PR review, maybe we don't. The era of reading every line of code in your codebase is over, and pretending otherwise is just performative engineering.

And honestly? That's fine. You don't need to read every line. You never really did.

But here's what's not fine — most of us have dropped below the minimum threshold of understanding. We've stopped reading the code, and along with it, we've lost something far more important than the "what" or the "how."

We've lost the why.

The "Why" Is the Only Thing That Matters

Think about your codebase right now. You probably know what it does — it's an API, a dashboard, a pipeline. You might even know how certain parts work — this service calls that service, data flows from here to there.

But can you answer these?

Why is the auth service separate from the main API?
Why did we pick Postgres over Mongo for this particular data model?
Why does this request go through three middleware layers before hitting the handler?
Why is this config hardcoded instead of environment-driven?

These are the questions that matter when things break at 2 AM. When a new hire asks "why is it like this?" and you realize you have no idea. When a security auditor asks why data flows through a particular path and you're guessing.

The "what" and "how" — those are recoverable. You can read the code, trace the flow, figure it out. But the "why" is almost never in the code itself.

Where the "Why" Actually Lives

Here's the uncomfortable truth: the reasoning behind most architectural decisions in your codebase exists in one of these places:

A Slack thread from 18 months ago that nobody can find
A meeting that was never recorded
The head of an engineer who left the company
A compliance requirement that was communicated verbally
A PR description that says "refactored auth module" with no further context

The code implies the why, but you need context to read between the lines. Without that context, you're just looking at the outcome of a decision with no way to trace it back.

And here's what makes this worse in 2026: AI-generated code doesn't even have a "why."

When Claude or Copilot writes a function, there was no design decision. There was no tradeoff discussion. There was a prompt, and there was output. The code works, but the reasoning layer — the intent — was never there to begin with. It was in the developer's head when they wrote the prompt, and it evaporated the moment they hit Enter.

"Just Write Better Commit Messages"

I know what you're thinking. I thought it too.

The obvious solution: capture the "why" in commit messages. You can even put it in your CLAUDE.md or agent rules — "always include the reason behind the change in commit messages." Discipline your team to do the same.

feat: split auth into separate service

Why: Compliance team requires auth logs to be isolated from
application logs for SOC2 audit trail. Shared DB made this
impossible without query-level filtering.

That's beautiful. That's exactly what a commit message should look like.

But here's the problem — we don't read commit messages either.

Be honest. When was the last time you ran git log and actually read through commit messages to understand why something is the way it is? We barely read code anymore. We're definitely not reading commit history.

Commit messages, PR descriptions, ADRs, design docs — they're all write-only mediums. People write them (sometimes), but nobody goes back to read them when it matters. The "why" gets captured but never retrieved.

The problem isn't capture. It's retrieval.

The Knowledge Tiers

So if we've accepted that we don't read code, and we've accepted that the "why" is the hardest thing to recover — what's the minimum you actually need to know?

Here's how I think about it:

Must Know (you're dangerous without this):

System boundaries — what are the services, what owns what
Data flow — how does a request travel through the system
Auth model — who can access what and how
Integration points — what external systems do we depend on

Should Know (you're effective with this):

Key design decisions and the reasoning behind them
Database schema and why it's structured that way
Error handling strategy — what happens when things fail
The constraints that shaped the architecture (compliance, scale, team size)

Can Look Up (don't waste brain space):

Implementation details of individual functions
Utility code and helpers
Specific algorithm choices
Configuration specifics

Don't Need:

Line-by-line understanding of every file

The critical insight: the "Must Know" and "Should Know" tiers are almost entirely about the why, not the what. You need to know why the system boundaries are where they are. Why data flows this way and not that way. Why the database schema looks like this.

The Real Test

Here's a simple test for whether you understand your codebase at the level that matters:

Can you explain why it's built this way — without opening the code?

Not what it does. Not how it works. Why this architecture. Why these tradeoffs. Why this database, this queue, this separation of concerns.

If you can't, you're below the line. And that's where most of us are right now, if we're honest about it.

The "Why" Needs to Be Surfaced, Not Just Stored

The real solution isn't writing better docs or more disciplined commit messages — though those help. The real solution is making the "why" available at the point where you need it.

Not buried in git history. Not scattered across Slack. Not locked in someone's head. But surfaced, structured, and accessible when you're actually making decisions about the code.

This is what I've been building with Revibe. It analyzes your codebase and reconstructs the architectural reasoning — the system boundaries, the design decisions, the "why" behind the structure. Not by reading your Slack (it can't), but by reading the code deeply enough to surface what's implicit.

It's not perfect. No tool can fully recover intent that was never documented. But it gets you above that minimum threshold — the point where you can answer "why is it built this way?" with something better than "I don't know, it was like this when I got here."

The Engineer's New Job

We've accepted that AI writes code. Fine.

But someone still needs to own the "why." Someone needs to know why the system is shaped the way it is, why these tradeoffs were made, why this architecture and not another.

That someone is you. And the uncomfortable truth is that as AI takes over more of the writing, the "why" layer is disappearing even faster — because AI doesn't have intent. It has instructions.

The engineer's job is shifting. It's no longer "write the code." It's "maintain the why."

And if you can't do that, it doesn't matter how good your AI agent is at writing code. You don't understand your codebase at the level that matters.

Revibe helps you understand any codebase — architecture, design decisions, and the reasoning behind the code. Try it free.

Coder Legion - Recent posts tagged git

No, Git Isn't Dead. Anthropic's Robots Just Needed a Bigger One.

You Deleted the .env File From Git. Your Secrets Are Still Public.

Why Deleting Doesn't Delete

Step 1: Rotate Everything First

Step 2: Find Out What Else Was Committed

Step 3: Remove It From History

The Leak That Has Nothing to Do With Git

Make It Hard to Repeat

The Rule

Oracle's Fusion Setup Registry Puts Configuration in a Public Git Repo for AI Agents

GitHub Classroom has closed: what you still have, and how to run next term

What happened, and when

What you still have

What is gone, or going

Finding your students' repositories

Before next term: a checklist

The options for next term

Sources

What AI Coding Loses That Git History Can't Tell You — B Donald Harris

Meet B Donald Harris

Why AI coding can leave developers with unanswered questions

Hindsight: Remembering the story behind software

How AI has changed Donald's approach to development

From a .NET developer tool to AI agentic workflows

Building BIT Voices and creating opportunities for others

Lessons from building products and communities

Watch the full conversation

About the interviewer: Tom Smith

About CoderLegion Dev Stories

Tags

surviving-lines scored highest in a six-arm code-ownership benchmark

What was measured

Sealed set

Public set

Other models

How much to trust the grading

What it costs and what went wrong

An earlier measurement: commit share against surviving lines

Try it and check it

You Ran git reset --hard and Panicked. Here's How to Get Your Commits Back (and the One Thing You Ca

What the Reflog Is

Disaster 1: git reset --hard Threw Away Commits

Disaster 2: You Deleted a Branch You Still Needed

Disaster 3: A Rebase Went Wrong

Disaster 4: You Dropped a Stash

The One Thing You Cannot Recover

Why Reflog Entries Do Not Last Forever

How to Make This Less Scary Next Time

The Rule

Why Git Blob IDs Mismatch Your File Checksums

Why Does Hashing Raw File Bytes Produce Another Value?

How Is UTF-8 Byte Length Different from String Length?

When Must Application Integrity Use a Separate Digest?

Additional Scenarios and Failure Modes

Execution and Verification Checklist

Conclusion

Alternatives to the DevLabs Pull Request Merge Conflict Extension (2026)

cover_image: https://jr-devtools.com/merge-conflict-resolver/screenshot-editor.png

Is the DevLabs extension still supported?

The alternatives

1. Resolve locally with Git (free)

2. Your IDE's Git integration (free)

3. Merge Conflict Resolver (free plan, Pro from $12 per organization per month)

Side by side

Switching from the DevLabs extension

Related guides

Use Git Sparse-Checkout to Scope Agent Worktrees

Setting Up Scoped Worktrees

Keeping Visibility Separate from Enforcement

Verification Checklist

Managing Agent Worktrees in Git

The Silent Hazard of Shared Git State

The Command Boundary

The Cattle Pattern for Agent Worktrees

Deterministic Scheduling

Conclusion

My First Project: From a Local Folder to GitHub Using Git and SSH

My First Project: From a Local Folder to Git hub Using Git and SSH

GIT

Disaster 1: `git reset --hard` Threw Away Commits