kranzky

Hi HN, I'm Kranzky (aka Jason Hutchens). I've been writing code for over 30 years, a good chunk of it in games, including the scripting system for Black & White at Lionhead, AI on L.A. Noire at Team Bondi, a Futebol MMO that never saw the light of day...

At Team Bondi we used Perforce, and I loved its Timelapse View, which I've missed badly since moving to Git many moons ago. So I finally built it, inspired by the Handmade / Better Software crowd and Jon Skinner's Sublime Text (Jon and I worked together on L.A. Noire).

Git Lineage allows you to

* open a file in a Git repo and drag the timeline. The view updates at up to 120fps while you drag. Lines are tinted by how recently they changed, and deleted lines linger as fading ghosts;

* search in realtime across the whole revision history, with matches shown on the timeline, and you can jump from one matching commit to the next, with results filtered by added or changed lines, deleted lines, or commit metadata;

* blame directories too, even to the point of double-clicking into a sub-directory deleted years ago to dig through the files within it; and

* much, much more; there's a user's manual and a video on the website that go into the details (I tested on the Linux repo, which the video shows, and also on the Rails repo).

Oh, I almost forgot: press E and Q to enable visual effects and sound effects, so scrubbing through history feels like being a hacker in a 90s movie ;)

Git Lineage was built with C++17, Dear ImGui on SDL3's GPU API, FreeType, libgit2 for objects and diffs, and the git CLI for history and blame. Blame for commits near the playhead is computed on background threads and cached in memory and on disk, and the cache evicts by distance from the playhead so it follows you as you scrub. On my M1 Pro, with a synthetic file of 1,000 commits and 5,000 lines, the first view appears in about 250 ms and moving to a cached revision shows new content in about 8 ms.

Confession time: This project was AI-assisted. I built it with Claude Code over six and a half months, shipping over 330 PRs, each one reviewed, tested by hand and merged by me. And I had to be very hands-on throughout actually, especially with performance, the blame caching and prefetching that make scrubbing smooth, threading bugs, and the UX.

Limitations: Git must be installed. Rename following is opt in and off by default. Merges make some transitions ambiguous. The first open of a big repo takes a while (you'll probably not notice a delay on your own projects). It is a history viewer, not a Git client: no staging, committing or branching or other features. Keep using what you're using, reach for Git Lineage when you have some code spelunking to do.

It's shareware: free and fully functional forever with unregistered copies showing a dismissible reminder. A one-time licence is US$29, with no device limit. Licences are verified offline, there's no account, and the only thing the app fetches is an optional update check. See https://gitlineage.com/stats for open stats covering page views, downloads, license purchases and revenue. I'll add a HACKERNEWS discount code for 50% off. I've sold 4 licenses so far and although I'm not doing this to make money and don't want to come across as a shill it is nice to have the validation that payment brings!

I'd love to hear if this project resonates with anyone. I know it's niche but it was fun to write and I love the idea of small, focused, efficient tools with native UI and game-inspired usability and features. Happy code spelunking!

A good problem for tech to solve is this: How do you turn a bunch of random strangers into a community?

You know you're in a community when people help each other move house, for example.

Tech heads are re-discovering what "community" actually means, after overusing and abusing the term for the last two decades when they actually meant to say "audience" or "network".

Just read an article about employers increasingly monitoring their WFH employees with software installed on their computers. This is the "sitting at a desk and typing" measure of productivity. How do they propose monitoring the "solving problems by thinking hard" measure of productivity?

For sure, we need to collectively recognise how much real work takes place in this mode.

I once collaborated with a colleague to design and implement a data sync framework. For six weeks we chatted about it during our lunch break, while walking from the office to a Japanese takeaway and back again. We'd propose ideas and find weaknesses and flaws in them, and would spend our evenings thinking hard to come up with solutions to get around these issues.

Our boss saw none of this, but it easily consumed about three weeks of person-hours (i.e. around 120 hours).

One day, walking back from lunch, neither of us could find any problems with our proposed solution. We walked into the office straight into a meeting room, spend 30 minutes drawing diagrams on a whiteboard, then returned to our desks and coded up a working proof-of-concept in a couple of hours.

From our boss's perspective, we had implemented a new technology in an afternoon. He's the kind of non-technical person who equates productivity with typing code into a computer. But I think more places need to equate productivity with sitting on a sofa staring into space, or going for long walks, or whatever it happens to be that works for the developer in question.

I know it's bleak, but the API now includes build server style badges, like this: https://corona.kranzky.com/badge.svg

Nice, I remember playing with Dasher many moons ago; visited David MacKay (RIP) back in 1996. In 2009 I developed my own text input system called D-Board. There's a brief video of a prototype here: https://www.youtube.com/watch?v=Do0fUWME0Mw

Source code of the prototype is here: https://github.com/kranzky/d_board

In fact, with the help of Paul Geerts, I submitted an earlier version of d-Board to SONY in 2006 or thereabouts while working in game development. It ran on the PS3 and used a similar interface to that shown in the video. The search menu in the PlayStation Store on PS4 later adopted this interface (although it's been replaced by an OSK these days), perhaps because somebody saw the prototype and decided they'd use it there.

I suggest you read "Bullshit Jobs: A Theory", by David Graeber.

He explains that apprentice -> journeyman -> master no longer holds; we all get stuck at journeyman, working in the service of others for our entire career.

You, my friend, need to start your own company.

Oh. Well, damn. I guess Steve Yegge was right. Anyway, wouldn't it be great if Google launched a kick-ass text editor?

Great stuff, and awesome to see this coming from Google (and in Rust instead of Go). Interesting historical note: The author of Sublime Text left Google to work on it by himself when he couldn't get it approved as a 20% project.

A semi-serious brain dump after working with GitHub's new features for a day.

Thinking about Chomsky and Hong Kong lead to writing this brain-dump.

This is obviously, I hope, all just a bit of fun.

Well, it is kind-of possible for Ruby/Rails. I half-built such a system once. Here's what you do:

* Gather coverage information when running tests or compiling assets.

* Use that to generate Rakefiles for running tests / compiling assets that have dependencies on the source files they would touch.

* Run the tests once, recording information about the git status of each dependency.

* When the git status of a file changes (i.e. you've just fetched some changes), mark the dependency as dirty

Even better, it you're gathering coverage data and know the test status for each commit, then not only can you show the commit that broke the build, you can show the particular part of the diff that broke the build.

Here's a guy who was trying to do some of this: https://github.com/Genki-S/ttnt

Things I would build:

* Push conflicted branches so developers in a distributed team can work together to resolve conflicts.

* A git-powered version of Rake, which runs only those tests that need to be run based on the git history since the last run.

* A tool to identify what code changes caused a particular test to fail, based on the above.

* Language syntax detection for smarter diffs, improving the display when blocks of code are moved around or indented/outdented.

* Language linters built in, to detect when a change is introducing a syntax error. Same for coding style.

I'd also move the "Close Pull Request" button a little farther away from the "Comment" button, and make it possible to add comments to a diff when you've hidden whitespace differences (with `&w=1`... I'd also make it a bit more obvious that you could do that).

Nice work! I built something similar that keeps everything in Ruby. It was made to allow models built in Excel by a non-programmer to be executed on the back-end of a Rails app, but it's pretty generic: https://github.com/agworld/soroban

I had big plans for the project; the next step was to convert the models to JavsScript so they could be executed directly on the client. But, like most of my pet projects, this has remained a pipe dream.

Good luck with it!

OK, fixed the autoscroll I think. Let me know if it does / doesn't work for you.

Thanks for the feedback; I did try to do the autoscroll, so sorry it's not working. Will attempt a fix soon...

I spent the last couple of weeks rewriting MegaHAL, and it's finally online again after a brief absence.

You can talk with MegaHAL here: http://megahal.kranzky.com/

All source is freely available on GitHub, unencumbered by a license.

The main MegaHAL repository is https://github.com/jasonhutchens/megahal/ It includes a console application and eight built-in personalities, including Sherlock Holmes. And it's easy to hook into its API if you want to build something else with it.

MegaHAL uses Sooth, which is a simple stochastic predictor, written in C but wrapped in a Ruby gem. It's available at https://github.com/jasonhutchens/sooth/ MegaHAL uses five separate Sooth predictors to do its thing. You could build other things with it.

Finally, the code for the server itself is available at https://github.com/jasonhutchens/megahal-server/ It's a Rails 4.2 app with a crappy Bootstrap theme. A basic REST api hooks things up, and a daemonized version of MegaHAL processes the queue of jobs coming in from the world.

Have fun, I'm looking forward to seeing how warped the online personality becomes, and how big the brain file grows.

Share and Enjoy!

I have spent the past few weeks rewriting MegaHAL in Ruby and getting it back online, after a brief absence.

You can chat with MegaHAL here: http://megahal.kranzky.com/

MegaHAL is also available as a Ruby gem, which includes a console mode, all open source and unencumbered by a license. See the GitHub page for more: https://github.com/jasonhutchens/megahal/

Enjoy!

Yes, the TDD debate really got me thinking about why I write tests. It used to be about saving me time. Now it seems to be about satisfying other people that I know what I'm doing.

But I am a fan of code-as-documentation, blindingly obvious business logic and data validations at the interface, and I was struck by how Uncle Bob's TDD example just disregards all of that. Hence the QDD piece (which is half serious, half joking; I've left it a puzzle for the reader to figure out which half is which).