rewind

Rewind is an intelligent archivist.

Explore on GitHub Read Hacker News discussions

2Distinct people

4Mentions

0Explicit recommenders

1.9KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Rewind is an intelligent archivist.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2013-11-01 20:33:38 UTC to 2021-08-05 23:24:09 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2013	2013-01-01 00:00:00 UTC	2014-01-01 00:00:00 UTC	1	1
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	0	0
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	2	2
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	1

What Hacker News says

4 sources

tessierashpool·Aug 5, 2021

me too. I have a set of git history analysis scripts that I often use when I'm joining a new team. they're here: https://github.com/gilesbowkett/rewind but they're a bit stale at the moment. one major weakness they have is that they work on a per-repo basis. no problem at all for monorepos, but for a company with a lot of repos, it'd make sense to use the GitHub GraphQL API to find out which repos see the most activity.

In Show HN: Visualizing a Codebase

ralmeida·Nov 11, 2015

There was a previous discussion here on HN that covered this in depth. You may find it interesting: https://news.ycombinator.com/item?id=9784008 In short, top-voted strategies include: - Try to find out "hotspots" in code using some scripting (e.g. https://github.com/gilesbowkett/rewind). According to user tessierashpool on the last thread: > we tend to view files in a list, but in reality, some files are very central, some files are out on the periphery and only interact with a few other files So, finding out where most things happen in the project is a good way to get up to speed. - "Deep-diving": starting from a high-level point (say, the moment you type ssh-keygen on your terminal), go down the subroutine rabbit hole. You're likely to cover a lot of ground this way. But really, read the previous discussion, many many great strategies

Read the rest

shared - many of which I already used before reading that discussion and some I've incorporated since.

In Ask HN: How do you navigate a new codebase?

tessierashpool·Jun 26, 2015

I wrote some simple bash scripts around git which allow me to very quickly identify the most frequently-edited files, the most recently-edited files, the largest files, etc. https://github.com/gilesbowkett/rewind it's for assessing a project on day one, when you join, especially for "rescue mission" consulting. it's most useful for large projects. the idea is, you need to know as much as possible right away. so you run these scripts and you get a map which immediately identifies which files are most significant. if it's edited frequently, it was edited yesterday, it was edited on the day the project began, and it's a much bigger file than any other, that's obviously the file to look at first. we tend to view files in a list, but in reality, some files are very central, some files are out on the periphery and only interact with a few other

Read the rest

files. you could actually draw that map, by analyzing "require" and "import" statements, but I didn't go that far with this. those vary tremendously on a language-by-language basis and would require much cleverer code. this is just a good way to hit the ground running with a basic understanding which you will very probably revise, re-evaluate, or throw away completely once you have more context. but to answer your actual question, you do some analysis like this every time you go into an unfamiliar code base. you also need to get an idea of the basic paradigms involved, the coding style, etc. -- stuff which would be much harder to capture in a format as simple as bash scripts. one of the best places to start is of course writing tests. Michael Feather wrote a great book about this called "Working Effectively with Legacy Code." brudgers's comment on this is good too but I have some small disagreements with it.

In Ask HN: How do you familiarize yourself with a new codebase?

tessierashpool·Nov 1, 2013

I do something similar with bash when I start a new project. Code's here: https://github.com/gilesbowkett/rewind It's just useful to profile the team in terms of who writes the most code, or to profile the project in terms of when it's seen the most activity. The first time I did this, it was a rescue project, and the people who we were rescuing didn't even bother to properly introduce us to the rest of the team (the real thing they needed rescuing from was team dysfunction), so I'd have been at a real disadvantage if I hadn't done the analysis.

In Discovering Senior Developers from Source Code History