I once pushed a commit to a client repo under my personal email. Nothing broke that
time — but in a regulated environment, the reverse mistake (work identity on a
personal project) is an audit conversation nobody wants.

After 18 years architecting software, I've learned that the most expensive bugs are
rarely in the code. They're in the seams around it. Git identity management is one
of those seams — and almost nobody talks about it.

Most developers no longer work under a single identity

A normal day:

• Contributing to your company's GitHub org
• A freelance client's GitLab repo
• Your own side projects
• Open-source contributions
• Repos that each demand different SSH keys, GPG keys, and credentials

Git is a brilliant tool. But it doesn't know your intent — it uses whatever profile
happens to be active. That gap is where the pain lives: lost productivity, broken
focus, avoidable mistakes, and the occasional compliance scare.

The four flavours of this pain

1. Wrong identity, wrong commit. You write an hour of code, push, and someone
says "that came from your personal account." Now you're amending commits, force-pushing,
and explaining yourself. The code was fine. The identity wasn't.

2. The endless config shuffle.

git config user.email "work@company.com"
# ...later...
git config user.email "me@gmail.com"

Each switch is under a minute. Over months, it's hours — and one forgotten switch
undoes all the savings.

3. SSH and GPG chaos. Separate keys per account, signed-commit requirements per
org. Pick the wrong key and a 10-second commit becomes a debugging session or a
rejected pipeline.

4. The cognitive tax. The biggest cost isn't technical — it's the flow-state
interruption every time you stop to ask "which identity am I right now?" Developers
should be thinking about architecture and the business problem, not Git plumbing.

The business angle (why an architect cares)

This scales past the individual: senior engineers burning time on other people's auth
failures, slower onboarding (new hires losing their first hour to Git setup), and
real audit risk from misattributed commits in regulated environments. A paper-cut at
the individual level is a process cost at the org level.

Grit: solve it from the other end

Instead of asking developers to switch configs manually, Grit manages Git identity
automatically in the background. No wrappers, no custom Git commands, no constant
reconfiguration. Just the right identity, every commit.

• Session-based memory — Grit remembers the profile for each repo and restores it when you return.
• Automatic detection — via .grit files, directory paths, or remote-URL patterns:

  ~/work/*              → Work Profile
  ~/opensource/*        → Open Source Profile
  github.com/my-company/* → Corporate Profile

• Pre-commit protection — a Git hook applies and verifies the correct identity before the commit is created, not after the mistake is found.
• SSH + GPG per profile — each profile carries its own key routing and signing config, cutting auth drift and rejected commits.
• Cross-platform daemon — runs quietly on Windows, Linux, and macOS.

The design lesson

The hard part was never switching identities — that's one shell command. The hard
part is deciding when to switch, reliably, without the developer ever thinking about
it. That's a rules-engine-and-fallbacks problem, plus defense-in-depth (the daemon
and the pre-commit hook guarding the same one-line mistake). Same architectural
muscle I've spent 18 years building, pointed at a paper-cut I lived with every day.

I'm also designing an enterprise tier for teams who need this with audit trails and
policy — more on that another time.

The point

The best developer tools are the ones you stop noticing. Software is complex enough;
the right Git identity should just be applied, every time, without costing you a single
thought.

Grit is open source and shipped. Pull it, break it, tell me what you'd do differently:
GRIT in GIT

If you've ever force-pushed to fix a wrong-identity commit — what happened?