It turns out, we have some great tools now for dealing with tedious chores. In particular, I’ve set up two tools that turned merge conflicts from a dreaded chore into a minor speed bump. Most of the time, they resolve themselves before I even see them. For the ones that don’t, automation handles the tedious parts so I only deal with the genuinely ambiguous cases.

The Problem with Textual Merging

Git’s built-in merge is purely textual. It compares lines of text and looks for overlapping changes. It doesn’t understand your code. It doesn’t know what a function is, or an import statement, or a class definition. It just sees lines.

This means Git reports conflicts that aren’t actually conflicts. Two developers add different imports to the same file, near the same spot. Git sees overlapping line changes and panics:

<<<<<<< HEAD
import { useState } from 'react';
import { useQuery } from '@tanstack/react-query';
=======
import { useState } from 'react';
import { useEffect } from 'react';
>>>>>>> feature/dashboard

A human can see instantly that both changes are independent additions. One added useQuery, the other added useEffect. The correct resolution is to keep all three imports. But Git can’t see that because Git doesn’t understand syntax. It only sees text.

These false conflicts add up. On a large rebase, they can turn a five-minute task into a thirty-minute slog.

Layer 1: Mergiraf

Mergiraf is a structural merge driver for Git. Instead of comparing lines of text, it parses your files using language grammars and merges at the syntax tree level. If two changes touch different parts of the syntax tree, it merges them cleanly. If they genuinely conflict at the structural level, it falls back to standard conflict markers.

That import example above? Mergiraf resolves it automatically. It understands that those are independent additions to an import list and combines them.

Mergiraf supports over 25 languages: Java, Rust, Go, Python, JavaScript, TypeScript, C, C++, C#, Ruby, Elixir, PHP, Dart, Scala, Haskell, OCaml, Lua, Nix, YAML, TOML, HTML, XML, and more. For file types it doesn’t support, it returns a non-zero exit code and Git falls back to its default textual merge. No harm done.

Setup

Three steps.

1. Install mergiraf:

brew install mergiraf

2. Register the merge driver in your ~/.gitconfig:

[merge "mergiraf"]
    name = mergiraf
    driver = mergiraf merge --git %O %A %B -s %S -x %X -y %Y -p %P -l %L

3. Apply it globally in ~/.config/git/attributes:

* merge=mergiraf

The wildcard (*) tells Git to run every file through mergiraf. This might sound aggressive, but it’s fine. If mergiraf doesn’t recognize the file type, it steps aside and Git handles it normally.

Companion Settings

Two additional Git settings complement mergiraf nicely.

diff3 conflict style: By default, Git’s conflict markers only show your version and their version. With diff3, you also see the common ancestor (the “base”). This gives both mergiraf and humans more context to resolve conflicts correctly.

[merge]
    conflictStyle = diff3

Here’s the difference. Standard conflict markers:

<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature

With diff3:

<<<<<<< HEAD
const timeout = 5000;
||||||| base
const timeout = 3000;
=======
const timeout = 10000;
>>>>>>> feature

The base section tells you the original value was 3000. Now you can see that HEAD changed it to 5000 and the feature branch changed it to 10000. Without the base, you’re guessing.

rerere (reuse recorded resolution): Rerere records how you resolve conflicts and automatically replays those resolutions if the same conflict comes up again. This is useful during rebases where you might encounter the same conflict multiple times.

[rerere]
    enabled = true

Layer 2: Automating the Rest

Mergiraf handles the structural conflicts, but some conflicts are genuinely ambiguous. And some aren’t ambiguous at all, they’re just tedious. Lock files, database migrations, stacked PR duplicates. Each of these has a clear resolution strategy, but you still have to do the work manually.

This is drudgery. Drudgery that follows clear rules. Perfect for automation.

I built a Claude Code skill called /resolve-conflicts that handles the entire conflict resolution workflow. Type /resolve-conflicts and it takes over.

How It Works

The skill follows a three-step loop:

1. Detect context. It reads Git’s internal state files to determine whether you’re in a rebase, merge, cherry-pick, or revert, and how far along you are (e.g., step 3 of 12 in a rebase).

2. Categorize and resolve. It runs a categorization script on every conflicted file, sorting them into buckets: lock file, migration, mergiraf-supported, or other. Then it resolves each bucket with the appropriate strategy.

3. Continue. It regenerates any lock files, runs the appropriate continue command (git rebase --continue, git commit --no-edit, etc.), and loops back to step 1 if more conflicts appear.

Resolution Strategies

Each category gets its own treatment:

Lock files: Accept theirs to clear the conflict markers, then regenerate. The content of a lock file is derived from the dependency manifest, so there’s no point resolving individual lines. The skill runs the appropriate package manager (npm install, cargo generate-lockfile, poetry lock --no-update, etc.) to produce a correct lock file from the resolved manifest.

Migrations: Ask the human. Migration files represent sequential schema changes where order matters. Getting this wrong can break your database. The skill flags these and asks you how to proceed.

Mergiraf files: Run mergiraf as a second pass. Even though mergiraf already ran as a merge driver during the git operation, sometimes conflicts remain (partial resolutions, complex restructuring). The skill runs mergiraf solve on the file. If conflict markers remain after that, it falls through to AI analysis.

Everything else: Read the conflict, analyze both sides, and resolve it. This is where the skill earns its keep on the genuinely tricky ones.

Stacked PR Duplicate Detection

If you work with stacked PRs, you’ve probably hit this one. You have a feature branch with sub-PRs stacked on top of each other. You merge a sub-PR into main. Now when you rebase the parent branch, Git produces conflicts where both sides have nearly identical code and the base section is empty.

Here’s what that looks like with diff3:

<<<<<<< HEAD
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}
||||||| base
=======
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}
>>>>>>> feature/add-checkout

Empty base. Both sides identical. This isn’t a real conflict. It’s just Git seeing that code appeared on both sides independently (once from the merged sub-PR, once from the feature branch that originally authored it).

The skill detects this pattern. When the base is empty but HEAD and the incoming side are more than 95% similar (after normalizing whitespace), it auto-resolves by keeping the HEAD version and tells you what it did. For 70-95% similarity, it shows both versions and asks you to confirm. Below 70%, it’s a genuine divergence and presents both options for you to decide.

A Realistic Session

Here’s what it looks like in practice. You’re rebasing and hit conflicts:

> /resolve-conflicts

Conflicts (rebase step 3/12):
- 1 lockfile: package-lock.json
- 2 mergiraf: src/app.ts, src/utils.ts
- 1 other: README.md

Resolving lockfile: package-lock.json... accepted theirs (will regenerate)
Resolving mergiraf: src/app.ts... resolved structurally
Resolving mergiraf: src/utils.ts... 1 conflict remains, analyzing...
  Auto-resolved src/utils.ts hunk at line 42: stacked PR duplicate
  (HEAD and incoming 98% similar with empty base). Kept HEAD version.
Resolving other: README.md... [presents conflict for user review]

Regenerating package-lock.json... done
Continuing rebase (step 4/12)...

If step 4 has conflicts, it resolves those too. All the way through step 12. You just watch it work and only chime in when it needs a human decision.

Setup

The skill lives in my dotfiles repo. If you use my dotfiles, it’s already available via symlink. Otherwise, grab the files and drop them into ~/.claude/skills/resolve-conflicts/.

Putting It Together

The two layers complement each other:

1. During any git merge, rebase, or cherry-pick, mergiraf runs automatically as the merge driver. It silently resolves structural conflicts before you ever see them. You don’t have to do anything.
2. For the conflicts that remain, /resolve-conflicts categorizes them, applies the right strategy for each type, and continues the operation.

The result: most rebases that used to require manual intervention now complete with zero or minimal human input. The conflicts that do need your attention are the genuinely ambiguous ones that deserve it.

Try It

Both tools are open source and available in my dotfiles repo. Mergiraf is available at mergiraf.org and installs in minutes. The resolve-conflicts skill requires Claude Code.

Merge conflicts are an inevitable part of collaborative development. The suffering is optional.

Yet there it was. My smiling face. On that PR.

This was my first year at PostHog, and it felt like a real test of the culture. Would they blame me? Let it quietly color opinions of my work? Fire me over a mistake?

Nah.

My colleagues were supportive and understanding. The question wasn’t “who do we blame?” but “what allowed this to happen and how do we prevent it?” This is a company that looks at failure through the lens of systems and incentives, not individual fault. It embraces the ideas of blameless post-mortems.

If we go with “blame” as the predominant approach, then we’re implicitly accepting that deterrence is how organizations become safer. This is founded in the belief that individuals, not situations, cause errors.

That moment is just one of many reasons why I love working here. This is a company that backs up its principles with action.

A Year of PostHog

A year ago today, I started at PostHog, and it has been even better than I hoped. When I joined, I wrote:

Their company handbook really impressed me. What it communicates to me is that this is a remote-friendly company that values transparency, autonomy, and trust. It’s a company that treats its employees like adults and tries to minimize overhead.

It is easy to be cynical about company handbooks and the values they claim to uphold. Enron famously promoted Integrity, Respect, Communication, and Excellence (RICE) as its values, but we all know how that turned out.

What has stood out to me at PostHog is that the handbook reflects reality. The company thinks deeply about how it wants to operate and is willing to adjust when things drift. At our most recent all-company off-site in Tulum, we even revisited and changed some of our values to better reflect how we actually work.

That kind of self-awareness is rare. It’s one big reason why I love working here. Also, Tulum.

Retirement Job?

When Microsoft acquired GitHub, it gave me a lot of options. I took time off. I started a YC company. That company did not work out, so I took more time off. I was not in a hurry to get back to work, but I did miss the camaraderie of building things with other people. That is what led me to interview at PostHog.

In my interview, one of the founders asked an interesting question. Given that it seemed like I did not need to work, would I be motivated to work hard at PostHog? In other words, was this a “retirement job”?

Of course I said I would work hard. What else could I say?

But here’s what I didn’t say: writing code and building product doesn’t feel like hard work to me, at least not compared to what I did before. As a Director of Engineering, so much of my energy went into bureaucracy, politics, and navigating bad incentives.

That was exhausting.

Writing code is how I unwind.

So in a way, yes, this is a retirement job. Because I love doing it.

Polyglot

I also still have a lot to learn, and this has been a great place to do it.

My team builds the Feature Flags product, which spans the backend service, the frontend UI, and a large collection of SDKs. Over the past year, I have written production code in Python, TypeScript, Rust, Go, Ruby, Elixir, C#, and even PHP.

Yes, PHP. I held out for thirty years. The streak is over.

At one point, I shipped the same ETag caching feature to seven different SDKs in seven different languages in three days.

I am not an expert in all of these languages. But with a solid foundation in programming principles, and a lot of help from LLMs, I have been able to ramp up quickly.

Working across so many languages and paradigms has stretched my thinking and deepened my understanding of how software systems are built.

Team Lead

A while back I wrote Chutes and Ladder career path about how careers do not have to follow a neat, linear ladder. True to that idea, after a year as an individual contributor, I am stepping into a team lead role.

This was not something I actively sought out. I genuinely love being an IC. But, as has often happened in my career, this change grew out of a real need. We are carving out a new Flags Platform team from the Feature Flags team. The good news is that a team lead role at PostHog is not a traditional management role. It’s effectively an IC with a bit more responsibilities for the team such as hiring, mentoring, and planning.

What excites me most about this split is the chance to focus deeply on the platform itself.

I am excited to see what year two brings. I will be spending a lot more time in Rust, pushing our flags platform to be faster and more resilient, and working my butt off to ensure my face stays out of future root cause analysis reports.

But that changed as I began using LLM coding tools to do more work in parallel. Being able to work on multiple branches simultaneously is a game changer.

Without git worktrees, working on multiple branches at the same time in the same repository is a pain. There’s the serial approach where you stash your changes, context switch, and pray you didn’t break anything. Or worse, just commit half-finished work with “WIP” messages (looking at you, past me). Or you can have multiple clones of the same repository, but that’s a pain to manage and can take up a lot of disk space.

Git worktrees solve this. They let you have multiple branches checked out simultaneously in different directories that all share the same git database (aka the .git directory). For me, this means I can work on a feature in one terminal, review a PR in another, have Claude Code work on another feature in another terminal, and have all of them share the same git history.

But here’s the thing: creating worktrees manually is tedious. You need to remember where you put them, what to name them, and clean them up later. Also, by default the git worktree is created in the root of the repository unless you specify a different directory.

I wanted something simpler. I wanted something that would work across any repository. No setup, no configuration files, just sensible defaults.

Enter tree-me

I built tree-me, a minimal wrapper around git’s native worktree commands. It adds organizational convention while letting git handle all the complexity.

Instead of this:

# Create worktree manually
mkdir -p ~/worktrees/my-project
git worktree add ~/worktrees/my-project/fix-bug -b haacked/fix-bug main
cd ~/worktrees/my-project/fix-bug
# Now repeat for every repo...

You do this:

tree-me create haacked/fix-bug
# Creates: ~/dev/worktrees/my-project/haacked/fix-bug
# And automatically cds into it

How it works

tree-me uses git-like subcommands and follows conventions so you don’t have to think:

• Auto-detects repository name from your git remote
• Auto-detects default branch (checks for origin/HEAD, falls back to main)
• Organizes by repo: $WORKTREE_ROOT/<repo-name>/<branch-name>
• Delegates to git for all validation, errors, and edge cases
• PR support: Fetches GitHub PRs using git’s native PR refs (requires gh CLI)
• Auto-CD: Automatically changes to the worktree directory after creation
• Tab completion: Complete commands and branch names in bash/zsh

Commands:

tree-me create <branch> [base]        # Create new branch in worktree
tree-me checkout <branch>             # Checkout existing branch (alias: co)
tree-me pr <number|url>               # Checkout GitHub PR (uses gh CLI)
tree-me list                          # List all worktrees (alias: ls)
tree-me remove <branch>               # Remove a worktree (alias: rm)
tree-me prune                         # Prune stale worktree files
tree-me shellenv                      # Output shell function for auto-cd

Examples:

tree-me create haacked/fix-bug              # Create from main/master
tree-me create haacked/fix-bug develop      # Create from develop
tree-me co existing-feature                 # Checkout existing branch
tree-me pr 123                              # Checkout PR #123
tree-me pr https://github.com/org/repo/pull/456
tree-me ls                                  # Show all worktrees
tree-me rm haacked/fix-bug                  # Clean up (supports tab completion)

Conventions

tree-me is a minimal wrapper around git’s native commands. Works with any repo, any language, any setup. The only convention is where worktrees live and how they’re named.

Want worktrees in a different location? Set WORKTREE_ROOT. Need to branch from develop instead of main? Pass it as an argument: tree-me create my-feature develop. Conventions with escape hatches.

Setup

To enable auto-cd and tab completion, add this to your ~/.bashrc or ~/.zshrc:

source <(tree-me shellenv)

This makes tree-me create, tree-me checkout, and tree-me pr automatically cd into the worktree directory. It also enables tab completion for commands and branch names (try tree-me rm <TAB>).

View the full implementation at github.com/haacked/dotfiles/blob/main/bin/tree-me.

The PR workflow

Here’s where it shines. Someone asks you to review a PR while you’re deep in a feature:

tree-me pr 123                  # Fetches, checks out PR, and cds into it
# You're now in: ~/dev/worktrees/dotfiles/pr-123
# Review the code, test it, leave comments
# When done, switch back
tree-me co haacked/my-feature   # Checks out and cds back to your feature
# Back to your work, no stash needed

When you’re done reviewing:

tree-me rm pr-123               # Tab complete to see available branches

Gone. Clean. No accidentally committing review changes to your feature branch.

Installation

Download tree-me and put it somewhere in your PATH:

# Example: copy to ~/bin or ~/.local/bin
curl -o ~/bin/tree-me https://raw.githubusercontent.com/haacked/dotfiles/main/bin/tree-me
chmod +x ~/bin/tree-me

Then enable auto-cd and tab completion (see Setup section above).

That’s it. No dependencies beyond git, bash, and optionally the gh CLI for PR checkout.

Why I built this

I work on multiple repos daily—PostHog, my blog, various open source projects. I was tired of remembering project-specific worktree scripts and hunting for that worktree I created last week.

The philosophy: Don’t recreate what git does well. Add only the minimal convention needed.

Git already handles worktrees perfectly. I just needed organized paths, sensible defaults, and a consistent interface across all my projects.

Directory structure

Everything is organized predictably based on the repository name and branch name:

~/dev/worktrees/<repo-name>/<branch-name>

For example:

~/dev/worktrees/
├── dotfiles/
│   ├── haacked/vim-improvements/
│   ├── haacked/git-tools/
│   └── main/
├── posthog/
│   ├── haacked/feature-flags/
│   ├── pr-789-contributor/
│   └── main/
└── spelungit/
    └── haacked/performance/

One glance and you know where everything is.

What it doesn’t do

tree-me doesn’t copy environment files, install dependencies, or set up project-specific tools. That’s deliberate. Those concerns belong in your project’s setup scripts, not in a generic git tool.

Want to automate environment setup? Add a script to your repo that runs after checkout. Want to copy .env files? Put it in your project’s onboarding docs. tree-me just handles the git worktree ceremony.

Try it

If you work with multiple branches regularly, give worktrees a try. If you work with multiple repos, give tree-me a try. If you hate it, at least you learned about git worktrees (and that’s probably worth more than the script).

Find tree-me at github.com/haacked/dotfiles/blob/main/bin/tree-me. It’s MIT licensed—copy it, modify it, improve it.

Git’s search is challenging for these sorts of queries. git log --grep="auth" assumes you remember exact words from commit messages. Want to find “commits where we improved error handling in API endpoints”? You’ll need multiple greps with regex gymnastics, and still miss commits that used different terminology. We need a better tool.

Enter Spelungit

I built Spelungit, a semantic search engine for Git commit history. Instead of keyword roulette, you search using natural language through Claude Code’s MCP interface.

Want commits where you refactored authentication? Ask for “authentication flow refactoring.” Looking for race conditions in background processing? Search for “race conditions in job processing.” It understands intent instead of making you guess exact words from three months ago.

How it works

Instead of this:

# How do you even grep for "race condition fixes"?
git log --grep="race\|concurrent\|thread\|lock\|mutex" --all
# Now manually read through 50 commits...

You do this in your AI development tool of choice:

Search git history for "race condition fixes in background jobs"

Queries that work:

• “When did we switch from REST to GraphQL?”
• “Commits where we improved error handling in API endpoints”
• “Show me refactoring of the authentication flow”
• “Security improvements in file upload handling”
• “Where did we fix that memory leak in the worker process?”

It creates embeddings for both commit messages and code changes, which makes semantic search possible. It knows the difference between new features and bug fixes, even when commit messages are vague (looking at you, past me).

Installation

Spelungit uses SQLite and local embeddings to make installation simple. Everything runs on your machine. No need for an API key, a database, or Docker.

One line:

curl -sSL https://raw.githubusercontent.com/haacked/spelungit/main/install-remote.sh | bash

Downloads everything, sets up Python venv, installs dependencies, configures Claude Code. Suspicious of pipe-to-bash? Clone the repo and run ./install.sh.

Using it

Shows up in Claude Code (or your AI tool of choice) as an MCP server. The first time you ask a question in a repository that spelungit responds to, spelungit will index the repository. Once it’s done, it’ll be able to answer questions.For large repos, this can take a few minutes while it analyzes commits and creates embeddings.

Then search naturally:

• “Show me commits about error handling improvements”
• “Find where we refactored the authentication”
• “What changed in the API layer recently?”

Claude calls the appropriate MCP tools (index_repository, search_commits, repository_status, get_database_info) behind the scenes.

Under the hood

Analyzes commit messages and code changes. For each commit:

• Semantic content from messages and diffs
• Code patterns like function names and classes
• File types and directory structure
• Feature vs. bug fix vs. refactoring

Uses Microsoft’s all-MiniLM-L6-v2 (384 dimensions) with local sentence-transformers to create embeddings. Embeddings are stored in SQLite. Searching for git history uses cosine similarity searches.

The sqlite database only stores commit SHAs and embeddings, leaving the full commit message in git. Thousands of commits = few megabytes. Handles Git worktrees if you’re into that masochism.

Why I built this

I work across multiple repositories and constantly need to understand why changes were made. Traditional Git tools are limited. Too much detective work scrolling through commits.

I wanted to ask Git history questions in plain English and get the right commits back. Semantic search of Git history is something I always wished GitHub would add. I got tired of waiting so I built this.

Also, I’ve been experimenting with MCP servers and wanted to build something useful instead of another todo app.

Future ideas for improvement

Configurable models: Local embeddings work pretty well, but OpenAI’s models would be better for teams willing to trade privacy for better accuracy. PostgreSQL support: For massive repos or shared team search. Smarter code understanding: Better refactoring vs. feature detection, architectural changes over time.

Try it

Spelungit is MIT licensed. The project scratched a real itch for me. If it doesn’t work perfectly, that’s what GitHub issues are for.

Find it at https://github.com/haacked/spelungit.

1. Checkout the default branch.
2. Run git up to make sure you’re up to date.
3. Run git bclean to delete all the branches that have been merged into the default branch.

And this worked great for a long time. The way it worked was it would list all the branches that have been merged into the default branch and then delete them. In my case, I didn’t use git branch --merged to list merged branches because I didn’t know about it at the time.

However, my aliases stopped working for me recently after joining PostHog. The main reason is on pretty much all of their repositories, they use Squash and Merge when merging PRs.

When you use git merge --squash or GitHub’s “Squash and merge” feature, Git creates a new commit on the target branch that combines all the changes from the source branch into a single commit. This new commit doesn’t retain any reference to the original commits from the source branch. As a result, Git doesn’t consider the source branch as merged, and commands like git branch --merged won’t show it.

But here’s the thing about Git. There’s almost always a way.

Solution

When you merge a PR on GitHub, it shows you a “Delete branch” button:

This is a great feature. It’s a good way to clean up branches that have been merged into the default branch. In fact, you can configure GitHub to “Automatically delete head branches” when merged:

I highly recommend you do the same. When the remote branch is deleted, Git will track it as “gone”. For example, if you run git branch -vv you’ll see something like this:

> git branch -vv

  haacked/decide-v4      ba39408 [origin/haacked/decide-v4: gone] Fix demo to handle variants
  haacked/fix-sample-app ec15751 [origin/haacked/fix-sample-app] Handle variants
* haacked/local-only     e78d2f6 Do important stuff
  main                   ab885d0 [origin/main] chore: Bump to v1.0.2

Notice that haacked/decide-v4 is marked as gone.

We can use git’s porcelain to list branches and their tracking information in a more easily parseable format.

> git for-each-ref --format='%(refname:short) %(upstream:track)' refs/heads/

haacked/decide-v4 [gone]
haacked/fix-sample-app
haacked/local-only
master

Let’s make this an alias to list these gone branches:

> git config --global alias.gone "!git for-each-ref --format='%(refname:short) %(upstream:track)' refs/heads/ | awk '\$2 == \"[gone]\" { print \$1 }'"

Now we can use the alias to list gone branches:

> git gone

haacked/decide-v4

Next step is to update my old bclean alias to use the new gone alias.

> git config --global alias.bclean "!git gone | xargs -r git branch -D"

Unfortunately, since git doesn’t know it’s been merged, we have to do a force delete. That’s a bit scary, but this won’t touch local branches or any branches that are still tracking a remote branch. With this alias, you can run git bclean to delete all the branches that have been merged into the default branch. Finally, we have the old bdone alias to switch to the default branch, run git up, and then run bclean.

Here’s the complete set of aliases mentioned in this post you can cut and paste into your .gitconfig:

[alias]
    default = "!git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'"
    bclean = "!git gone | xargs -r git branch -D"
    # Switches to specified branch (or the default branch if no branch is specified), runs git up, then runs bclean.
    bdone = "!f() { DEFAULT=$(git default); git checkout ${1-$DEFAULT} && git up && git bclean; }; f"
    gone = "!git for-each-ref --format='%(refname:short) %(upstream:track)' refs/heads/ | awk '$2 == \"[gone]\" { print $1 }'"

Or, if you want to use the git command line, you can use the following:

git config --global alias.default "!git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'"
git config --global alias.gone "!git for-each-ref --format='%(refname:short) %(upstream:track)' refs/heads/ | awk '\$2 == \"[gone]\" { print \$1 }'"
git config --global alias.bclean "!git gone | xargs -r git branch -D"
git config --global alias.bdone "!f() { DEFAULT=\$(git default); git checkout \${1:-\$DEFAULT} && git up && git bclean; }; f"

fatal: ref refs/remotes/origin/HEAD is not a symbolic ref

git remote set-head origin --auto

So now, my old workflow is back. When I merge a PR, I can run git bdone from the branch I merged to clean up the branches. All is right with the world again.

And as always, you can find these aliases and more in my dotfiles repo. See this blog post for more context on how you can include them in your dotfiles.

I joined PostHog at the beginning of the year as a Product Engineer on the Feature Flags team. Feature flags are just one of the many tools PostHog offers to help product engineers build better products.

Much of my job will consist of writing Python and React with TypeScript. But when I started, I noticed they didn’t have a .NET SDK. It turns out, I know a thing or two about .NET!

So if you’ve been wanting to use PostHog in your ASP.NET Core applications, yesterday is your lucky day! The 1.0 version of the PostHog .NET SDK for ASP.NET Core is available on NuGet.

dotnet add package PostHog.AspNetCore

You can find documentation for the library on the PostHog docs site, but I’ll cover some of the basics here. I’ll also cover non-ASP.NET Core usage later in this post.

Configuration

To configure the client SDK, you’ll need:

1. Project API Key - from the PostHog dashboard
2. Personal API Key - for local evaluation (Optional, but recommended)

By default, the PostHog client looks for settings in the PostHog section of the configuration system such as in the appSettings.json file:

{
  "PostHog": {
    "ProjectApiKey": "phc_..."
  }
}

Treat your personal API key as a secret by using a secrets manager to store it. For example, for local development, use the dotnet user-secrets command to store your personal API key:

dotnet user-secrets init
dotnet user-secrets set "PostHog:PersonalApiKey" "phx_..."

In production, you might use Azure Key Vault or a similar service to provide the personal API key.

Register the client

Once you set up configuration, register the client with the dependency injection container.

In your Program.cs file, call the AddPostHog extension method on the WebApplicationBuilder instance. It’ll look something like this:

using PostHog;

var builder = WebApplication.CreateBuilder(args);

builder.AddPostHog();

Calling builder.AddPostHog() adds a singleton implementation of IPostHogClient to the dependency injection container. Inject it into your controllers or pages like so:

public class MyController(IPostHogClient posthog) : Controller
{
}

public class MyPage(IPostHogClient posthog) : PageModel
{
}

Usage

Use the IPostHogClient service to identify users, capture analytics, and evaluate feature flags.

Use the IdentifyAsync method to identify users:

// This stores information about the user in PostHog.
await posthog.IdentifyAsync(
    distinctId,
    user.Email,
    user.UserName,
    // Properties to set on the person. If they're already
    // set, they will be overwritten.
    personPropertiesToSet: new()
    {
        ["phone"] = user.PhoneNumber ?? "unknown",
        ["email_confirmed"] = user.EmailConfirmed,
    },
    // Properties to set once. If they're already set
    // on the person, they won't be overwritten.
    personPropertiesToSetOnce: new()
    {
        ["joined"] = DateTime.UtcNow 
    });

Some things to note about the IdentifyAsync method:

• The distinctId is the identifier for the user. This could be an email, a username, or some other identifier such as the database Id. The important thing is that it’s a consistent and unique identifier for the user. If you use PostHog on the client, use the same distinctId here as you do on the client.
• The personPropertiesToSet and personPropertiesToSetOnce are optional. You can use them to set properties about the user.
• If you choose a distinctId that can change (such as username or email), you can use the AliasAsync method to alias the old distinctId with the new one so that the user can be tracked across different distinctIds.

To capture an event, call the Capture method:

posthog.Capture("some-distinct-id", "my-event");

This will capture an event with the distinct id, the event name, and the current timestamp. You can also include properties:

posthog.Capture(
    "some-distinct-id",
    "user signed up",
    new() { ["plan"] = "pro" });

The Capture method is synchronous and returns immediately. The actual batching and sending of events is done in the background.

Feature flags

To evaluate a feature flag, call the IsFeatureEnabledAsync method:

if (await posthog.IsFeatureEnabledAsync(
    "new_user_feature",
    "some-distinct-id")) {
    // The feature flag is enabled.
}

This will evaluate the feature flag and return true if the feature flag is enabled. If the feature flag is not enabled or not found, it will return false.

Feature Flags can contain filter conditions that might depend on properties of the user. For example, you might have a feature flag that is enabled for users on the pro plan.

If you’ve previously identified the user and are NOT using local evaluation, the feature flag is evaluated on the server against the user properties set on the person via the IdentifyAsync method.

But if you’re using local evaluation, the feature flag is evaluated on the client, so you have to pass in the properties of the user:

await posthog.IsFeatureEnabledAsync(
    featureKey: "person-flag",
    distinctId: "some-distinct-id",
    personProperties: new() { ["plan"] = "pro" });

This will evaluate the feature flag and return true if the feature flag is enabled and the user’s plan is “pro”.

.NET Feature Management

.NET Feature Management is an abstraction over feature flags that is supported by ASP.NET Core. With it enabled, you can use the <feature /> tag helper to conditionally render UI based on the state of a feature flag.

<feature name="my-feature">
    <p>This is a feature flag.</p>
</feature>

You can also use the FeatureGateAttribute in your controllers and pages to conditionally execute code based on the state of a feature flag.

[FeatureGate("my-feature")]
public class MyController : Controller
{
}

If your app already uses .NET Feature Management, you can switch to using PostHog with very little effort.

To use PostHog feature flags with the .NET Feature Management library, implement the IPostHogFeatureFlagContextProvider interface. The simplest way to do that is to inherit from the PostHogFeatureFlagContextProvider class and override the GetDistinctId and GetFeatureFlagOptionsAsync methods. This is required so that .NET Feature Management can evaluate feature flags locally with the correct distinctId and personProperties.

public class MyFeatureFlagContextProvider(
    IHttpContextAccessor httpContextAccessor)
    : PostHogFeatureFlagContextProvider
{
    protected override string? GetDistinctId() =>
       httpContextAccessor.HttpContext?.User.Identity?.Name;
    
    protected override ValueTask<FeatureFlagOptions> GetFeatureFlagOptionsAsync()
    {
        // In a real app, you might get this information from a database or other source for the current user.
        return ValueTask.FromResult(
            new FeatureFlagOptions
            {
                PersonProperties = new Dictionary<string, object?>
                {
                    ["email"] = "some-test@example.com",
                    ["plan"] = "pro"
                },
                OnlyEvaluateLocally = true
            });
    }
}

Then, register your implementation in Program.cs (or Startup.cs):

using PostHog;

var builder = WebApplication.CreateBuilder(args);

builder.AddPostHog(options => {
    options.UseFeatureManagement<MyFeatureFlagContextProvider>();
});

This registers a feature flag provider that uses your implementation of IPostHogFeatureFlagContextProvider to evaluate feature flags against PostHog.

Non-ASP.NET Core usage

The PostHog.AspNetCore package adds ASP.NET Core specific functionality on top of the core PostHog package. But if you’re not using ASP.NET Core, you can use the core PostHog package directly:

dotnet add package PostHog.AspNetCore

And then register it with your dependency injection container:

builder.Services.AddPostHog();

If you’re not using dependency injection, you can still use the registration method:

using PostHog;
var services = new ServiceCollection();
services.AddPostHog();
var serviceProvider = services.BuildServiceProvider();
var posthog = serviceProvider.GetRequiredService<IPostHogClient>();

For a console app (or apps not using dependency injection), you can also use the PostHogClient directly, just make sure it’s a singleton:

using System;
using PostHog;

var posthog = new PostHogClient(
  Environment.GetEnvironmentVariable("PostHog__PersonalApiKey"));

Examples

To see all this in action, the posthog-dotnet GitHub repository has a samples directory with a growing number of example projects. For example, the HogTied.Web project is an ASP.NET Core web app that uses PostHog for analytics and feature flags and shows some advanced configuration.

What’s next?

With this release done, I’ll be focusing my attention on the Feature Flags product. Even so, I’ll continue to maintain the SDK and fix any reported bugs.

If anyone reports bugs, I’ll be sure to fix them. But I won’t be adding any new features for the moment.

Down the road, I’m hoping to add a PostHog.Unity package. I just don’t have a lot of experience with Unity yet. My game development experience mostly consists of getting shot in the face by squeaky voiced kids playing Fortnite. I’m hoping someone will contribute a Unity sample project to the repo which I can use as a starting point.

If you have any feedback, questions, or issues with the PostHog .NET SDK, please reach file an issue at https://github.com/PostHog/posthog-dotnet.

After over a year of being on a personally funded sabbatical, I started a new job at PostHog as a Senior Product Engineer. This week is my orientation where I get to drink from the firehose once again.

What is PostHog?

Apart from being a company that seems to really love cute hedgehogs, PostHog is an open-source product analytics platform. They have a set of tools to help product engineers build better products. Each product can be used as a standalone tool, but they’re designed to level-up when you put them together.

In particular, I’ve started on the Feature Flags team. Yesterday was my first day of onboarding and so far I really like my team.

Today is day two and I’ve already submitted a small fix for my first pull request!

Why PostHog?

When I was looking around at companies, an old buddy from GitHub who worked at PostHog reached out to me and suggested I take a look at this company. He said it reminded him of the good parts of working at GitHub.

Their company handbook really impressed me. What it communicates to me is that this is a remote-friendly company that values transparency, autonomy, and trust. It’s a company that treats its employees like adults and tries to minimize overhead.

Not only that, they’ve embraced a lot of employee-friendly practices. For example, a while back my friend Zach wrote about his distaste for the 90 day exercise window. PostHog provides a 10-year window. Not only that, they offer employes double trigger acceleration!

This is a perk usually only offerered to executives.

I should mention we’re hiring! Please mention me if you apply. If we’ve worked together, let me know so I can provide feedback internally.

I’m excited to be part of a company that’s small, but growing. The company is at a stage similar to the stage GitHub was at when I joined. This is a team with a strong product engineering culture and I’m excited to contribute what I can and learn from them.

The Challenge

The other part that’s exciting for me is that I’ll be working in a stack that I don’t have a huge amount of experience with. The front-end is React with TypeScript and the back-end is Django with Python. I’ve done a bit of work in all these technologies except Django. However, I believe my experience with ASP.NET MVC will help me pick up Django quickly.

Not to mention, I’ve always taken the stance that I’m a software engineer, not just a .NET developer. Don’t get me wrong, I love working in .NET. But at the same time, I think it’s healthy for me to get production experience in other stacks. It’ll be an area of personal growth. Not to mention, they don’t quite have a .NET Client SDK yet so once I get settled in, that’s something I’m interested in getting started on.

The Future

I’ll share more about my experience here as I get settled in. In the meanwhile, wish me luck!

For example, I came across an API that returned a value like this:

{
  "important": true
}

No problem, I defined a class like this to deserialize it to:

public class ImportantResponse
{
    public bool Important { get; set; }
}

And life was good. Until that awful day that the API returned this:

{
  "important": "What is important is subjective to the viewer."
}

Damn! This philosophy lesson broke my client. One workaround is to do this:

public class ImportantResponse
{
    public JsonElement Important { get; set; }
}

It works, but it’s not great. It doesn’t communicate to the consumer that this value can only be a string or a bool. That’s when I remembered an old blog post from my past.

April Fool’s Joke to the Rescue

When I was the Program Manager (PM) for ASP.NET MVC, my colleague and lead developer, Eilon, wrote a blog post entitled “The String or the Cat: A New .NET Framework Library where he introduced the class StringOr<TOther>. This class could represent a dual-state value that’s either a string or another type.

The concepts presented here are based on a thought experiment proposed by scientist Erwin Schrödinger. While an understanding of quantum physics will help to understand the new types and APIs, it is not required.

It turned out his blog post was an April Fool’s joke. But the idea stuck with me. And now, here’s a case where I need a real implementation of it. But I’m going to name mine, StringOrValue<T>.

A modern StringOrValue<T>

One nice thing about implementing this today is we can leverage modern C# features. Here’s the starting implementation:

[JsonConverter(typeof(StringOrValueConverter))]
public readonly struct StringOrValue<T> : IStringOrObject {
    public StringOrValue(string stringValue) {
        StringValue = stringValue;
        IsString = true;
    }

    public StringOrValue(T value) {
        Value = value;
        IsValue = true;
    }

    public T? Value { get; }
    public string? StringValue { get; }

    [MemberNotNullWhen(true, nameof(StringValue))]
    public bool IsString { get; }

    [MemberNotNullWhen(true, nameof(Value))]
    public bool IsValue { get; }
}

/// <summary>
/// Internal interface for <see cref="StringOrValue{T}"/>.
/// </summary>
/// <remarks>
/// This is here to make serialization and deserialization easy.
/// </remarks>
[JsonConverter(typeof(StringOrValueConverter))]
internal interface IStringOrObject
{
    bool IsString { get; }

    bool IsValue { get; }

    string? StringValue { get; }

    object? ObjectValue { get; }
}

We can use the MemberNotNullWhen attribute to tell the compiler that when IsString is true, StringValue is not null. And when IsValue is true, Value is not null. That way, code like this compiles just fine without raising null warnings:

var value = new StringOrValue<string>("Hello");
if (value.IsString) {
    Console.WriteLine(value.StringValue.Length);
}

and

var value = new StringOrValue<SomeType>(42);
if (value.IsValue) {
    Console.WriteLine(value.ToString());
}

It also is decorated with the JsonConverter attribute to tell the JSON serializer to use the StringOrValueConverter class to serialize and deserialize this type. I wanted this type to Just Work™. I didn’t want consumers of this class have to bother with registering a JsonConverterFactory for this type.

This also explains why I introduced the internal IStringOrObject interface. We can’t implement the JsonConverter attribute on a open generic type, so we need a non-generic interface to apply the attribute to. It also makes it easier to write the converter as you’ll see.

/// <summary>
/// Value converter for <see cref="StringOrValue{T}"/>.
/// </summary>
internal class StringOrValueConverter : JsonConverter<IStringOrObject>
{
    public override bool CanConvert(Type typeToConvert)
        => typeToConvert.IsGenericType
           && typeToConvert.GetGenericTypeDefinition() == typeof(StringOrValue<>);

    public override IStringOrObject Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        var targetType = typeToConvert.GetGenericArguments()[0];

        if (reader.TokenType == JsonTokenType.String)
        {
            var stringValue = reader.GetString();
            return stringValue is null
                ? CreateEmptyInstance(targetType)
                : CreateStringInstance(targetType, stringValue);
        }

        var value = JsonSerializer.Deserialize(ref reader, targetType, options);

        return value is null
            ? CreateEmptyInstance(targetType)
            : CreateValueInstance(targetType, value);
    }

    static ConstructorInfo GetEmptyConstructor(Type targetType)
    {
        return typeof(StringOrValue<>)
                   .MakeGenericType(targetType).
                   GetConstructor([])
               ?? throw new InvalidOperationException($"No constructor found for StringOrValue<{targetType.Name}>.");
    }

    static ConstructorInfo GetConstructor(Type targetType, Type argumentType)
    {
        return typeof(StringOrValue<>)
            .MakeGenericType(targetType).
            GetConstructor([argumentType])
            ?? throw new InvalidOperationException($"No constructor found for StringOrValue<{targetType.Name}>.");
    }

    static IStringOrObject CreateEmptyInstance(Type targetType)
    {
        var ctor = GetEmptyConstructor(targetType);
        return (IStringOrObject)ctor.Invoke([]);
    }

    static IStringOrObject CreateStringInstance(Type targetType, string value)
    {
        var ctor = GetConstructor(targetType, typeof(string));
        return (IStringOrObject)ctor.Invoke([value]);
    }

    static IStringOrObject CreateValueInstance(Type targetType, object value)
    {
        var ctor = GetConstructor(targetType, targetType);
        return (IStringOrObject)ctor.Invoke([value]);
    }

    public override void Write(Utf8JsonWriter writer, IStringOrObject value, JsonSerializerOptions options)
    {
        if (value.IsString)
        {
            writer.WriteStringValue(value.StringValue);
        }
        else if (value.IsValue)
        {
            JsonSerializer.Serialize(writer, value.ObjectValue, options);
        }
        else
        {
            writer.WriteNullValue();
        }
    }
}

In the actual implementation of StringOrValue<T>, I implemented IEquatable<T>, IEquatable<StringOrValue<T>> and overrode the implicit operators:

public static implicit operator StringOrValue<T>(string stringValue) => new(stringValue);
public static implicit operator StringOrValue<T>(T value) => new(value);

This allows you to write code like this:

StringOrValue<int> valueAsString = "Hello";
StringOrValue<int> valueAsNumber = 42;

Assert.Equals("Hello", valueAsString);
Assert.Equals(42, valueAsNumber);

So with this implementation in place, I can go back to the original example and write this:

public class ImportantResponse
{
    public StringOrValue<bool> Important { get; set; }
}

And now I can handle both cases:

var response = JsonSerializer.Deserialize<ImportantResponse>(json)
    ?? throw new InvalidOperationException("Deserialization failed.");

if (response.Important.IsValue) {
    if (response.Important.Value) {
        Console.WriteLine("It's important!");
    }
    else {
        Console.WriteLine("It's not important.");
    }
}
else {
    Console.WriteLine(response.Important.StringValue);
}

It’s time to go shopping for a beanie!

Here’s the full implementation for those interested in using this in your own projects!

If you’re lucky, your company supports a tall Individual Contributor (IC) ladder. But often, the next rung swaps your hoodie for a power shirt, suspenders, and management duties.

My first job followed this script: developer to team lead to Senior Manager. I was hustling up that ladder.

But life isn’t linear. Careers are more like Chutes and Ladders (which the Brits know as Snakes and Ladders, but that messes up my metaphor). Lucky breaks shoot you up; surprises send you sliding down. Those chutes? Not failures. Opportunities.

Take my journey. I took a chute from my first job back to an IC role at my second. Climbed back up into management. Took a chute to Microsoft as a Senior Program Manager. Then came another chute: GitHub.

I started as a developer, became a manager, then Director of Engineering. After that, I co-founded a startup, took the CTO title, but spent most of my time writing code.

It looked like the classic ladder climb, but in startups, titles are smoke and mirrors. So it only counted as a step up if we succeeded. Spoiler: we didn’t.

Ladders Are Overrated

Ladders are narrow and rigid. Titles—while shiny—hide what matters: the work. They’re bumper stickers for your career. Nice for signaling, but they don’t tell the whole story.

As Director, I mentored teams and focused on broad initiatives. But over time, I started to miss the tech. The longer I stayed out of writing production code, the more disconnected I felt. As a CTO, I got back to coding and loved it. When the startup failed, I promised myself at least a year off to reflect before jumping into something new.

Growth on the Slide

Over a year later, I’ve been thinking about my next move. It turns out nobody will pay me to be a man of leisure.

Conventional wisdom (and ego) says aim higher: VP of Software Development or CTO at an established company.

The irony of big titles is they mean more power at work, but less power over your time.

For me, my recent life circumstances make time autonomy among my top priorities. Sure, big titles pay well, but maximizing income isn’t my goal.

Here’s what I realized: By my own definition, I’ve succeeded. I’ve been part of great teams, built great products, and helped grow companies. I have nothing left to prove. I don’t need a lofty title or a giant paycheck (but I wouldn’t turn one down either).

So, once again, I’m setting aside my pride and stepping off the ladder. Next year on January 6th I start a new IC role. Details to come, but I’m thrilled to be back in the trenches, building and learning. It’s a place that treats its employees like adults and gives me the autonomy to structure my day as I see fit.

This isn’t about rejecting leadership. It’s about recalibrating. Leadership is broad. It’s guiding organizations or leading by example. I think it’s healthy—even advantageous—to bounce between IC and management roles over the course of a career. Life changes. I might return to management someday. Or not. The point is to stay open to what fits now.

Your Move

If you’re staring at a chute, wondering if stepping off the ladder will hurt you, consider this: maybe it’s not a setback. Maybe it’s a shortcut to what you really want.

Careers aren’t about perfect titles. They’re about collecting experiences, relationships, and skills that shape you. Sometimes, the most important moves don’t look like progress—until you’re somewhere unexpected, doing work that matters.

Spin the dial. Take the slide. Even in Chutes and Ladders, the winner isn’t who climbs highest. It’s who enjoys the game. At least, that’s what I told my friends when they beat me.

So I’ll spare you the long scroll and start this post with a git bisect cheat sheet and then I’ll tell you about my trip to hell that lead me to write this post.

$ git bisect start
$ git bisect bad                 # Current version is bad
$ git bisect good v2.6.13-rc2    # v2.6.13-rc2 is known to be good
. # Repeat git bisect [good|bad] until you find the commit that introduced the bug
$ git bisect reset

The One Where Poor Phil is Stumped

Like Groot, I was stumped.

I’m learning Blazor by building a simple app. After a while of working in a feature branch, I decided to test a logged out scenario.

When I tried to log back in, the login page was stuck in an infinite redirect loop.

I tried everything I could think of. I found every line of code that did a redirect and put a breakpoint in it, none of them were hit. I allowed anonymous on the login page. I tried playing with authorization policies. No dice. I asked Copilot for help. It offered some support and good advice, but it led nowhere. I even sacrificed two chickens and a goat, but not even the denizens of the seven hells could help me.

I switched back to my main branch to see if the bug was there, and lo and behold it was! That meant this bug had been in the code for a while and I hadn’t noticed because I was always logged in.

Often, when faced with such a bug, you might go on a divide and conquer mission. Start removing code you think might be related and see if the bug goes away. But in my case, that would encompass a large search area because I had no idea what the cause was or where to start cutting.

It was clear to me that some cross-cutting concern was causing this bug. I needed to find the commit that introduced it to reduce the scope of my search. Enter git bisect.

Git Bisect to the Rescue

From the docs:

This command uses a binary search algorithm to find which commit in your project’s history introduced a bug. You use it by first telling it a “bad” commit that is known to contain the bug, and a “good” commit that is known to be before the bug was introduced. Then git bisect picks a commit between those two endpoints and asks you whether the selected commit is “good” or “bad”. It continues narrowing down the range until it finds the exact commit that introduced the change.

The key thing to note here is that it’s a binary search. So even if the span of commits you’re searching is 128 commits, it’ll take at most 7 steps to find the commit that introduced the bug (27 = 128).

Here’s how I used it:

$ git bisect start # Get the ball rolling.
$ git bisect bad   # The current commit is bad.

Now I need to supply the last known good commit. That could be a search of its own, but usually you have a good idea. For example, you might know the last release was good so you use the tag for that release.

In my case, I found the commit, 543ada5, where I first implemented the login page because I know it worked then. Yes, I do test my own code.

$ git bisect good 543ada5
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[9736e3f90b571bebf512c2acb1f7ef14f3a77df4] Update all the NPMs

After calling git bisect good with the known good commit, git bisect picked a commit between the bad and good commit, 9736e3f.

I tested that commit and it turns out the bug wasn’t there! So I told git bisect that commit was good.

$ git bisect good
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[b9db65316a7f569c3ef9ed1eb4caa2072a6ba5d8] Show guests on Details page

After a few more iterations of this, git bisect found the commit that introduced the bug.

4e08eb48956b80a7a33987df272d30acb5bd6ee2 is the first bad commit
commit 4e08eb48956b80a7a33987df272d30acb5bd6ee2
Author: Phil Haack <haacked@gmail.com>
Date:   Thu Oct 10 15:38:21 2024 -0700

That commit seemed pretty innocuous but I did notice something odd.

I made this change in the App.razor file because I was tired of adding render mode InteractiveServer to nearly every page.

- <Routes />
+ <Routes @rendermode="InteractiveServer" />

It turns out, this change wasn’t exactly wrong, just incomplete. I can save the proper fix as a follow-up post. I’m annoyed that Copilot wasn’t able to offer up the eventual solution because I found it by googling around.

Now that I found the culprit, I can get back to my original state before running git bisect by calling git bisect reset.

Challenges with Git Bisect

I encourage you to read the docs on git bisect as there are other sub-commands that are important.

For example, sometimes a commit cannot be tested, such as a broken build. In that case, you can call git bisect skip to skip that commit.

In practice, I found cases where you have to do a bit of tweaking to get the commit to run. For example, one commit had the following build error:

error NU1903: Warning As Error: Package ‘System.Text.Json’ 8.0.4 has a known high severity vulnerability

At the time that I wrote that commit, everything built fine. Since I only want to build and test locally, I ignored that warning in order to test the commit.

Automating Git Bisect

The reason I bring up these challenges is git bisect has the potential to be automated. You could write a script that builds and tests each commit. If a commit fails to build or test, the script could call git bisect skip for you.

For example, it’d be nice to do something like this:

git bisect run dotnet test

This would run dotnet test on each commit and automatically call git bisect skip if the test fails.

However, in practice, it doesn’t work as well as you’d like. Commits that were fine when you wrote them might not build any longer. Also, what you really probably want to do is inject a new test to be run during the git bisect process.

Not to mention if you have integration tests that hit the database. You’d have to have migrations run up and down during the process of git bisect.

I’ve considered building tooling that would solve these problems, but in my experience, so few .NET developers I know make regular use of git bisect that it’s hard to justify the effort. Maybe this post will convince you to add this tool to your repoirtoire.