Implementing Branches Comparison on gitg

The past three weeks have been crazy for me, I’ve been taking my finals, as well as working on my Graduation Project(it’s my graduating semester). I’ve also been talking and discussing different designs for my GSoC project with the amazing GNOME designer Tobias Bernard. We’ve been discussing what would be the best approach to provide a better user experience.

We decided that it would be better to have a separate activity for the “comparing” outside the “History Activity”, however it should be accessed via a context menu from the “History Activity”. There will be a video at the end of the blog post illustrating the workflow.

I’ve been also thinking what would be the best way to implement this without affecting the performance of gitg or increasing it’s memory consumption. One concern I had is that the commit lists models would consume a lot of RAM. Also loading them simultaneously would be an overkill for the CPU, especially for very large repositories. I had to ask for the best way to approach this problem, you could see my question here on Stack Overflow, where one of the maintainers of the libgit2 Library answered me.

Also just to give a background of what should be the final design, there should be a new activity called “Compare Activity”. It will mainly have three views, the first view “Main View” is to gather which branches will be compared against each other, the second view “Branch View” used to show the commits difference between the two branches, and the last view “Commits View” would show two selected branches side by side allowing the user to select a commit from each branch to be compared. Here are some sketches of what has been designed so far, and what will be soon:

Compare Activity’s Main View

Compare Activity’s Branch View

Compare Activity’s Commits View

These are the following optimizations that came into mind:-

1. Only load list models on demand
2. Share the same RevisionWalker across the different list models
3. Load models in the “Compare Activity” serially to make use of the RevisionWalker cache, also to save some memory
4. Only load the last 1000–2000 commits for each branch, we don’t really need more than that, it’s not that common that users would want to compare between very old commits. However it might be changed(maybe there should be an option for it in the preferences in gitg)
5. When the view is not in use, purge it’s model to free some memory.

So far what have been implemented, is the first and the second views(Main and Branch Views). You could try it out on my MR and give it a run, I would love to hear your feedback for this, and if there is anything that should be done to increase it’s usability, or if there is anything that should be fixed(keep in mind though that this isn’t final and it’s still a WIP, in fact it’ll probably go through a lot of changes according to my mentor “Alberto Fanjul” and Tobias feedbacks). You could see the workflow in the video below:-

In the next few days, I’ll be testing this more and making sure everything is working correctly, and I’ll begin working on the last view, so wish me good luck.