Building a Meta-Logger: Tracking My Work Across GitHub, Codeberg, and Bitbucket Using Go

Modern development isn’t just fragmented across repositories — it’s fragmented across platforms.
On any given week, I might:

• Fix a production bug in a Bitbucket repo at work
• Push an open-source contribution to Codeberg
• Ship a side-project feature on GitHub

Each platform has its own dashboards, contribution graphs, and activity feeds.

None of them talk to each other.

After a while, I noticed a real problem:

I had no reliable way to answer “What have I actually contributed, where, and how much?”

Not because the data didn’t exist — but because it was siloed.

The Problem: Contribution Blindness

This wasn’t about chasing green squares or streaks.
It was about:

• Losing visibility into my own work
• Forgetting entire weeks of meaningful contributions
• Having no portable, platform-agnostic record of progress
• Manually reconstructing timelines whenever I needed a summary

When someone asked:

“What did you work on last month?”

The answer involved:

• Opening GitHub
• Then Bitbucket
• Then Codeberg
• Searching commit histories
• Mentally stitching together context

That’s a tooling failure.

The Insight: Git Is the Only Common Denominator

Platforms differ.

Git does not.
Whether a repo lives on GitHub, Codeberg, Bitbucket, or a self-hosted server, every commit has:

• A hash
• An author
• A timestamp
• A message
• A repository context

So instead of trying to unify platforms, I decided to unify my commits.

That led to a simple idea:

What if every commit I make, anywhere, automatically logs itself into one central place?

What I Built: A Meta-Logger

I built a small Go-based CLI tool I call a Meta Logger.

It creates a meta-repository — not for code, but for context.

This repository becomes

• A centralized journal of my work
• A searchable, chronological history
• A platform-independent “proof of work”

The tool works silently in the background and requires zero manual effort once set up.

Architecture Overview

The system has three moving parts:

1. The Log Repository

A dedicated Git repository (hosted anywhere — GitHub is just convenient) that stores:

• A Markdown file (commit-log.md)
• One entry per commit, across all projects

It does not store source code.

2. A Go CLI Tool

A single binary written in Go that:

• Extracts commit metadata
• Formats human-readable log entries
• Commits and syncs them to the log repository

No runtime dependencies. No daemon. No background service.

3. Git Hooks

A post-commit hook installed into each working repository.

Every time I run:

git commit

The logger runs automatically.

No extra commands. No discipline required.

Why Go?

I chose Go for two very practical reasons:

1. Speed
   
   This runs on every commit. If it’s slow or flaky, it’s dead. Go binaries start instantly.

2. Zero Dependencies
   
   One compiled binary. No Node. No Python. No virtualenvs. No node_modules.

The commit workflow should be invisible.

How It Works in Practice

Setup

Running:

go run main.go setup

Does three things:

1. Initializes a central log repository
2. Creates a Markdown log file
3. Injects a post-commit hook into selected repositories

The hook is minimal:

#!/bin/bash
cd /path/to/workspace
go run main.go log-commit

From this point on, logging is automatic.

Automatic, Invisible Logging

On every commit, the tool captures:

• Repository (service) name
• Branch
• Commit hash
• Author
• Original commit date
• Full commit message

And appends a structured Markdown entry like this:

## [dummy-service] a1b2c3d - 2025-05-10 14:30:00

- **Service:** dummy-service
- **Branch:** main
- **Commit:** a1b2c3d
- **Author:** Nimai
- **Date:** 2025-05-10 14:29:58
- **Message:** 

This lives in a single file that GitHub (or any Git host) makes instantly searchable.

Importing My Entire Past

Logging forward wasn’t enough.

I wanted my entire history reflected.

That’s what import-history does.

go run main.go import-history

It:

• Iterates through all repositories
• Filters commits by author
• Reconstructs entries in chronological order
• Preserves original commit dates

Preserving Time Correctly

Git normally assigns now as the commit time.

That would destroy historical accuracy.

So while committing to the log repo, I explicitly inject the original dates:

cmd.Env = append(os.Environ(),
    "GIT_AUTHOR_DATE="+commitDate,
    "GIT_COMMITTER_DATE="+commitDate,
)

The result: the log repository becomes a faithful mirror of my actual work timeline.

Silent Syncing by Design

One important design choice: never block the developer.

If GitHub (or any remote) is unreachable:

• The log file is still updated locally
• The push is attempted silently
• Failures are ignored

The next successful push syncs everything naturally.
No broken workflows. No lost commits.

Why This Works Across Platforms

This system doesn’t care whether a repository lives on:

• GitHub
• Codeberg
• Bitbucket
• Or a local Git server

As long as it’s Git, it’s logged.

The log repository itself can live anywhere — GitHub just happens to give a great UI for browsing Markdown.

What This Gave Me

After a few weeks of usage, I had:

• A single, chronological journal of my work
• A platform-agnostic contribution record
• A way to answer “What did I work on?” instantly
• A clear signal of consistency and growth over time

No dashboards. No metrics. Just facts.

What This Is Not

• Not a productivity tracker
• Not a replacement for GitHub contributions
• Not a SaaS product
• Not something that spies on you

It’s just Git, documenting Git.

Closing Thoughts

This tool changed how I perceive my own output.

Instead of fragmented activity scattered across platforms, I now have a unified narrative of my work — one that I own completely.

Sometimes the most useful tools aren’t new abstractions.

They’re just honest layers on top of systems that already work.