Exciting News: GitChronicles is Now Free on the macOS App Store!

I’m thrilled to announce that GitChronicles, a powerful Git repository analytics software, is now available for free on the macOS App Store. You can download it here:

What is GitChronicles?

GitChronicles is designed to help you understand a project’s development patterns, highlight contributors’ impact, and visualize the evolution of codebases. But its capabilities extend far beyond that - keep reading to learn more.

100% Local Processing: Your Code, Your Data

I’m a big fan of software that runs locally, without sharing code or commits with third-party servers. One of the key benefits of GitChronicles is that it operates entirely on your local machine. This ensures that your code never leaves your device. Nevertheless, you can still analyze public Git repositories by cloning them locally. In fact, this is exactly how GitChronicles got started.

The Story Behind GitChronicles

I created GitChronicles to solve a personal problem I faced: assessing potential new dependencies for large projects I work on. When considering adding a new dependency, I realized it’s not just about gaining a new feature - it’s also about taking on a potential long-term commitment. Dependencies can become extremely costly and burdensome over time, yet many developers rush into them without thorough evaluation, often without any consideration at all.

I’ve always been reluctant when it comes to adding new dependencies to a project. Unless a dependency provides significant value and is essential to achieving a specific goal, I’m hesitant to introduce it. But it’s not about me, however. In many cases, proposals for new dependencies come from various stakeholders who require them to be discussed and evaluated.

When considering a new dependency, your first question should always be: ‘What problem are we trying to solve here?’ However, that’s not the only factor to consider. There are additional aspects to take into account, particularly the long-term implications of introducing new dependencies. A company or developer can become heavily invested in a dependency, which can be extremely costly as projects evolve and may also introduce unnecessary complexity or technical debt.

Whenever I started evaluating new dependencies, I found myself repeatedly asking the same questions: Who are the primary contributors behind this project? Are they still actively engaged, or have they moved on? What’s the current contribution trend - is it consistent, growing, or declining? How frequently are releases made, and what’s the overall pace of development? How many key contributors are there, and is the workload distributed evenly among them or dominated by one person? Has the project undergone any significant changes, such as a migration, and if so, is it progressing smoothly or stalled?

These questions sparked the idea for GitChronicles, a tool designed to offer rapid insights into a project’s development patterns, contributor landscape, and overall health. By addressing these questions, I sought to create a solution that would enable developers like myself to make more informed decisions when assessing potential dependencies, ultimately reducing the risk of accumulating unnecessary technical debt.

Initially, I tried to find individual key performance indicators (KPIs), such as the bus factor, but soon realized that these metrics did not provide sufficient insight. For example, I wanted to see which file types were the most important, whether the project was in a migration phase from one technology to another and which contributions were the most important, which contributions have survived over time until today and whether a new maintainer has taken over the work, etc.

The Challenge of Identifying Contributors

As I dug deeper into the contributor analysis, I came across a common problem: many users have multiple identities due to email address changes and repeated Git name setup - this made it difficult as the same contributor’s contributions were spread across multiple identities. To quickly solve this problem, after importing a Git repository, there was the idea of ‘auto-mapping’, which allows you to automatically assign different identities to the same person they belong to. For cases in which the identities cannot be assigned, the option of assigning them manually was created.

Exporting Git Map Files

The “auto-map” function led to another function: Wouldn’t it be nice if we could export Git mail map files (.mailmap) so that other Git tools could use them as well?

More Features Inside

Actually, I just wanted to announce that GitChronices is now free but started talking about the history and even individual features. There are even more features inside and much more details, but that’s stuff for new blog posts to come.

But you don’t need to wait. Get started today!