DEV Community: Supun Hewagamage

I built a developer layer on top of Git — and just released v1.0

Supun Hewagamage — Sun, 14 Jun 2026 01:25:30 +0000

Every time I onboarded someone onto a codebase, I'd watch them hit the same wall. They'd stare at git log, scroll through Slack threads trying to figure out why a decision was made, and ask "which files are related to the auth feature?" — questions that Git simply doesn't answer.

Git is brilliant at tracking what changed. But it doesn't know why. It doesn't know that these 12 files belong to the OAuth feature, or that the team decided to use JWT over sessions back in March, or that the new developer should read the auth module before touching the API layer.

So I built GOT.

What is GOT?

GOT sits on top of Git as a thin layer. It doesn't replace Git. It doesn't fork Git. It doesn't even modify Git internals. All it does is add capabilities that Git leaves on the table:

Workspaces — group related files, branches, decisions, and PRs into logical contexts
Decisions — structured architecture decision records (ADRs) linked to commits and code
Notes — quick context that stays attached to the work, not buried in Slack
Onboarding — guided sessions so new devs don't have to "just read the code"
GitHub integration — manage PRs and issues without leaving the terminal
Snapshots — automatic recovery points before destructive operations
Safe commands — got safe reset, got safe push, got safe rebase with a safety net

Everything lives in a .got/ directory. Add it to .gitignore and your repo stays clean. Your teammates can keep using plain Git and nothing breaks.

The philosophy

Five principles guided every design decision:

Git is the source of truth. GOT never modifies Git in ways you didn't ask for.
Metadata is isolated. Everything in .got/. Remove it and Git doesn't notice.
Offline-first. No network calls except the ones you initiate.
Plugin-first. Core features use the same event bus and plugin API available to extensions.
Recoverable. Destructive operations create automatic snapshots first.

What it actually looks like

# Initialize in any Git repo
cd your-project
got init

# Create a workspace to track a feature
got workspace create oauth --description "OAuth 2.0 implementation"
got workspace add-file oauth src/auth/oauth.go
got workspace add-branch oauth feat/oauth2

# Record an architectural decision
got decision create "Use JWT tokens for auth" --status accepted
got decision link <id> --auto   # links to your current commit

# See everything about a feature in one place
got workspace show oauth

# Safe operations — automatic snapshot before destructive git ops
got safe reset --mode hard HEAD~3
got safe push origin main

The got workspace show command is probably my favorite. It pulls together files, branches, decisions, PRs, and recent commits — all in one view. No more context-switching between git log, gh pr list, and scattered notes.

The technical bits

GOT is written in Go. A few things I'm proud of:

Pure Go SQLite via modernc.org/sqlite — no CGo, so cross-compilation just works. Binary runs on macOS, Linux, and Windows.
Interface-based Git adapter — all Git operations go through a GitAdapter interface that shells out to git via os/exec. Mockable in tests, swappable to libgit2 later.
Event-driven architecture — an in-memory pub/sub bus connects all modules. When a commit happens, the workspace engine, plugins, and integration layer all react automatically.
Plugin system — external binaries that communicate via JSON over stdin/stdout. A failing plugin never crashes GOT. 21 event types they can subscribe to.
130+ tests with the race detector, running on every push via GitHub Actions.

Building it was the hard part (and the fun part)

This project started as a spec — a 24-section design document that mapped out every feature, every data model, every CLI flag before a single line of code was written. Some people think that's overkill for a side project. But having that spec meant I never had to stop and wonder "how should this work?" The answer was already written down.

The hardest part wasn't the code. It was deciding what not to build. The spec had ideas for TUI dashboards, AI-powered commit suggestions, full-text search across decisions, and GitLab/Bitbucket integrations. All of those are future work. v1.0 ships what's solid and tested.

The most satisfying part? The test suite. There's something deeply comforting about running go test -race ./... on 130+ tests and seeing them all pass. Especially when you're building tooling that people will trust with their Git repositories.

What's next

The roadmap for v1.1 includes an interactive TUI dashboard built with Bubbletea and a full E2E test suite using testscript. Beyond that, I'm thinking about full-text search across decisions (SQLite FTS5), workspace templates, and maybe an AI layer for drafting decision records.

But honestly? I'm just excited to see if this is useful to other people. That's the real test.

Try it

go install github.com/supunhg/got/cmd/got@latest

Or clone and build from source:

git clone https://github.com/supunhg/got.git
cd got
make build

Then in any Git repo:

got init
got status
got workspace create my-feature

The repo is at github.com/supunhg/got. Issues, PRs, and stars are all welcome. If you build a plugin, I'd love to hear about it.

GOT is MIT licensed. It works offline. It doesn't phone home. And it won't touch your Git repo unless you ask it to.

Filo-Go v0.5.1 Released

Supun Hewagamage — Fri, 12 Jun 2026 04:03:17 +0000

🚀 Filo-Go v0.5.1

Today I'm happy to announce the first stable release:

The goal of Filo-Go is to provide a unified forensic analysis platform that can replace workflows involving multiple tools such as Binwalk, file, ExifTool, and strings.

Highlights

REST API server
Docker support
Interactive HTML reports
Streaming analysis pipeline
Analysis result caching
Plugin system
MCP integration
YARA support
Firmware analysis capabilities
Security hardening improvements

Quality Improvements

This release also focuses heavily on engineering quality:

79.6% test coverage
Zero lint issues
GitHub Actions CI/CD
Apache 2.0 licensing
Improved documentation and benchmarking

Real Performance Benchmarks

One lesson learned during development is that benchmark claims must be measurable and reproducible.

Earlier benchmark experiments produced unrealistic numbers, so I rebuilt the benchmarking process and published reproducible results based on actual workloads.

Current measured results against Binwalk:

Operation	Speedup
PNG Analysis	193.86×
ZIP Analysis	216.78×
Random 10MB Blob Scan	13.94×

Benchmark scripts and raw results are included in the repository for verification.

Known Limitations

Not every operation is faster.

For example:

filo strings is still slower than GNU strings on large inputs.
filo hash is slightly slower than dedicated hash utilities.

I'm intentionally documenting these tradeoffs because performance claims without context are not useful.

What's Next?

Future work includes:

Additional forensic modules
Expanded firmware support
More analysis formats
Better reporting capabilities
Continued performance optimization

Building Filo-Go has been one of the most educational projects I've worked on as a cybersecurity student, touching everything from file formats and malware analysis to API design, testing, benchmarking, and systems programming.

Repository: filo-go

Feedback, bug reports, and contributions are welcome.

Building filo-go: Reimagining Digital Forensics in Go

Supun Hewagamage — Tue, 09 Jun 2026 04:48:30 +0000

As a cybersecurity student, I spend a lot of time working with tools like Binwalk, ExifTool, file, strings, and YARA.

They're powerful, but the workflow is fragmented.

Analyzing a suspicious file often means bouncing between multiple tools, different output formats, and various dependencies.

So I started building Filo-Go.

What is Filo-Go?

Filo-Go (Forensic Intelligence & Learning Operator) is a Go-based digital forensics and file intelligence toolkit.

The goal is simple:

Provide a single, fast, cross-platform binary for common forensic analysis tasks.

Current capabilities include:

File identification and analysis
Entropy visualization
Metadata extraction
String extraction
Firmware analysis
Executable analysis (PE, ELF, Mach-O)
YARA scanning
PCAP analysis
SQLite inspection
Plugin support
MCP integration for AI-assisted workflows

Why Go?

I wanted something that is:

Fast
Easy to distribute
Cross-platform
Dependency-light

Go checked every box.

Why Am I Building It?

Partly because I need it.

Partly because I want to better understand how forensic tools work internally.

And partly because building systems like this is one of the best ways to learn software engineering, cybersecurity, reverse engineering, and digital forensics.

What's Next?

I'll be sharing architecture decisions, implementation details, performance benchmarks, and lessons learned as the project evolves.

Repository: filo-go

Feedback, ideas, and contributions are welcome.