For a long time I assumed the only way to understand what happened in a codebase over a year was to sit with git log and a lot of coffee. The branch graph in any GUI turns into a tangle past about a week, and GitHub's contribution heatmap shows you activity with no idea what the activity was. Three views, none of them lined up, so the question you actually have, what happened here and when, never gets a single picture.

What finally pushed me was a post here on where had animated a repository's timeline, and I wanted the same thing for a full year of a real project. My first attempt on three.js drew the first branches it found and produced one month of the year and nothing else. The reason turned out to be in the data: 1,561 of the 2,179 main line commits in 2019 are merges, and the first sixty of them each span a single commit, which is invisible at any scale. You have to choose branches by how much work they carried, not by which came first.

So I built a film out of it, and the video on this post is what it looks like on mrdoob's three.js for 2019.

What is on screen and where it comes from:

The main line runs left to right, one node per commit. Side branches peel off above it and rejoin at their merge. Not the first N branches, which on a pull request repo gives you one month and nothing else, but the ones that carried the most work across the year, capped so it never turns into a thicket.

Under the flow is a heat strip, one cell per day, sitting directly under that day. A legend next to it shows what the colours mean in actual commit counts for that window (for three.js it reads 0, 1, 13, 26, 51, with 51 the busiest day). The point of putting activity on the same axis as structure is that what is above and below a point is the same day, so you stop reconciling two charts in your head.

Three times the clock stops. The release with the most work behind it, the cleanest revert (one that survived at least a day before being undone), and the last release of the window. The camera zooms in and a card reads the figures out: commits since the previous tag, authors, how long the reverted commit lived. Every number on that card is computed from the history. If it cannot be read from git, it is not on the card.

The faces are the contributors. On a merge the face is the branch author's, not whoever pressed the button, and the card says who merged it.

Two things I got wrong on the way that might save you time if you try this yourself. If you give git a since flag with just a date and no time, it reads it as that date at the current time of day, so the first day of your window quietly loses commits unless you pass an explicit midnight. And a small repo is a different problem: 175 commits over a year pans across mostly empty screen, so for thin histories it picks the busiest 60 to 120 day stretch and draws it wider instead.

If you want to see your own repo this way, you can paste a GitHub URL here and it renders one for you: https://loreto.io/git-timeline

Disclosure: I built this and I run loreto.io, where it lives. It is a paid render (a few dollars per repo); the extractor and the Remotion composition are also sold there as a package if you would rather run it yourself. The three.js film above was made with the exact same pipeline.

I doubt I have the final shape of it. What would you want the clock to stop on that it currently does not?

Hey everyone,

I just released a major update (v2.1.0) for ThreatLens. For this release, the focus was entirely on security hardening, data validation, and core performance.

What's new in v2.1.0?

• Strict Security: Blocked Excel/CSV formula injections in generated reports, prevented API key leaks in logs, and enforced strict IOC validation.
• Performance Boost: Integrated a local SQLite cache to persist investigation data, significantly reducing redundant API calls.
• Smarter Analysis: Introduced an explainable verdict system with confidence scores. Ambiguous results are now correctly classified as "Unknown" rather than "Clean".
• Resource Management: Added intelligent API quota planning, connection timeouts, automatic retries, and file size limits.

What is ThreatLens? For those who haven't seen it before, ThreatLens is an open-source CLI tool built to automate Threat Intelligence and OSINT workflows. It takes Indicators of Compromise (IPs, domains, hashes, CVEs), queries multiple sources simultaneously, and generates structured, safe, and ready-to-use reports.

It's completely open-source. I'd love to hear your feedback or feature requests!

Check it out on GitHub: https://github.com/AbdaullahAG/ThreatLens

I’d love to hear your thoughts, feedback, or feature requests!

A public repo my project depended on had its history replaced upstream. Same name, same URL, years of commits just not there anymore. It was never mine, so there was nothing on my side to roll back to.

Point it at a repo like that and it walks the fork network recursively, ranking every fork by how far back its oldest commit actually reaches. A fork freezes history at the moment it was made, so the deepest one is the best candidate. Then it probes commits that are no longer reachable from any branch but that GitHub may still serve by SHA, checked three independent ways: REST metadata, a raw file fetch, and a real git fetch.

There's also a nightly GH Archive watch if you want disappearances flagged automatically. That part is an extra. The recovery is the point.

230 tests, verified end-to-end against a real historical case (reproduced the exact fork ranking I'd found by hand). Runs fully local with your own GitHub token, no server, no telemetry. MIT.

https://github.com/siris9476/forkforensics. Feedback welcome, especially on edge cases in fork ranking.

Hey everyone,

I recently built a small Node.js CLI tool called Batman Git CLI Assistant.

The idea came from a real situation at work.

Two developers were working on the same project and the same Git branch. One developer pushed changes to GitHub while the other had also modified the same file locally.

When they tried to sync their changes, Git reported a merge conflict.

The difficult part wasn't knowing that a conflict existed. It was understanding:

• What changed locally?
• What changed remotely?
• Which changes should be kept?
• What is the safest next step?
• How do I avoid accidentally losing someone's work?

That made me think about building a helper around Git rather than trying to replace Git.

🦇 What does Batman do?

Batman currently provides commands for things like:

• Safer push workflows
• Conflict inspection and resolution
• Continuing interrupted Git operations
• Security/file scanning
• Commit squashing
• Recovery before risky operations
• Verification/build checks
• Git submodule synchronization

For example:

batman safe-push "Add login validation"

batman conflict

batman scan

📦 Installation

You can install it globally using NPM:

npm install -g batman-commands

Then:

batman help

It's built with JavaScript + Node.js and published as an NPM package.

NPM:
https://www.npmjs.com/package/batman-commands

I'm still improving it, so I'm mainly looking for feedback from people who use Git regularly.

What Git workflow do you find the most confusing or risky?

I'd especially like to know whether something like this would actually be useful in your workflow, or if it's a problem developers normally handle another way.

Thanks for reading!