GSoC Final Report of GNOME gitg Work

Hi everyone, GSoC is coming to an end, and I’d like to present you with all the changes I’ve made so far on gitg.

I’ve learnt a lot while working on gitg, it’s really well-structured with a great architecture design. I didn’t have to refactor that much of code while extending it’s functionality, and I was amazed by how well-written and extendible it was.

Blog Posts History

All of the blogs can be found under my account on medium, here are links to them:-

1. My GSoC Proposal Got Accepted For GNOME
2. Back On Track
3. Implementing Branches Comparison on gitg

What Work Has Been Done?

My project issue (you can see it here), didn’t have a design proposal at first, so I had to try different implementations to see what would provide the best user experience.

So first, I created a prototype for selecting multiple commits in the History Activity and show the diff for them in the DiffView. I’ve created a MR for it, it didn’t and it shouldn’t be merged since I was just experimenting and trying to understand how gitg internal components/classes work. You can see a blog post about it here.

Then I’ve contacted Tobias Bernard(GNOME Designer) to discuss with him different approaches to implement this features, and we agreed that it should be in a separate Activity that can be accessed only from the History Activity to make the user workflow easier.

So I’ve made a second MR where I implemented all of the Project’s Goals, and it became fully functional. In this MR, I’ve created a new Compare Activity, where it implements two important features: comparing branches, and comparing any two selected commits from any two branches. You can also see a blog post about it here

What Has Been Merged?

Nothing have been merged yet, I’m waiting my mentor’s review and feedback, so that we can re-work and optimize parts that need more work

Deliverables, Work Details and Links

Prototype: Compare Two Non-Consecutive Commits

Regarding the prototype code, I’ve created a MR for it on gitg.
Here’s the MR: Compare Two Non-Consecutive Commits

Here is the complete work I’ve done on that prototype with links to it’s commits:-

1. Adding multiple selection to the History Activity CommitListView (Commit Link)
2. Refactoring History Activity to support the multiple selection functionality (Commit Link)
3. extending Gitg.Commit class to get diff with another commit object passed to it (Commit Link)
4. creating a new class that manages inserting/clearing commit from the DiffView (Commit Link)
5. refactoring DiffView and Diff to use the newly created class (Commit Link)

In this MR, I’ve tried extending the GitgCommitListView to support selecting multiple commits, refactored History Activity to support the new selection functionality, and refactored both DiffPlugin and DiffView to support multiple selection and showing the “diff” between them.

Final Project: Extending `gitg` with a new Compare Activity That Supports Comparing Branches/Commits

Regarding the Final Project, I’ve created a MR for it on gitg.
Here’s the MR: Creates A New Compare Activity That Handles Comparing Between Two Different Branches/Commits

The complete list of work is also written on the MR, this just lists the work done with the corresponding links to commits.

This MR, as previously mentioned, creates a new Compare Activity in gitg.

Inside the Compare Activity, three views are implemented:-

1. MainView, in which the users will be able to select different branches
2. BranchView, in which will be shown the difference of commits between the two selected branches in a GitgCommitListView
3. CommitsView, in which will be shown the two branches' commits, where users will be able to select two commits to compare, each from different branch.

I had to extend the backend as well as create the new Activity on the frontend, so here is the work done on the backend so far:-

1. extending libgitg with a new Popover to list the available branches (Commit Link)
2. modifying GitgCommitModel to be able to share the same RevisionWalker across different models (Commit Link)
3. GitgDiffView updates the diff on Idle, which will enhance the responsiveness of the application in case of huge diff between two commits (Commit Link)
4. adding new GitgRefActionCompare which if selected, will set the selected branch as one of the branches to be compared automatically, then make a transition to the Compare Activity (Commit Link)

Here is the work done on the frontend so far:-

1. decide what’s the best way to implement it, whether to share the same RevisionWalker, or to create two models for the two branches with different RevisionWalker (I had to try it myself to see if there were any impact on the performance, here’s my work on a side pet-project. Also I had to ask on Stack Overflow to get a proper feedback and opinion on what would be the best option, here’s the link of my question)
2. create the MainView of the Compare Activity (Commit Link)
3. Show a message to users on the MainView if the selected repository was a bare one (Commit Link)
4. create a BranchView, where comparison between branches is shown, e.g. Gitlab, and Github (Commit Link)
5. create a CommitsView, where comparison between two different commits from different/same branch is shown (Commit Link)
6. reload Compare Activity whenever there is a change in the repository, or new commits added (Commit Link)

What’s Left To Do?

Most of the things that I planned to do, has been already implemented on the Final Project MR, ready to be reviewed by my mentor Alberto Fanjul so that we can rework the necessary parts, if needed.

Future Plans

I’m planning to improve the DiffView of gitg to improve showing “diffs” since it may introduce some lagging on the UI if the “diff” between two commits was huge. I’ll work with my mentor (Alberto Fanjul) to refactor it and see what we can do to improve it’s performance.

Also I’m planning on continuing my work on an old MR for the “highlighting changes within lines” feature, here’s it link

Challenges and Learnings

I’ve enjoyed working on gitg a lot, it has been challenging for me to understand the details of certain implementations in the program. Also gitg is a complex project, so it was hard at first to get the grasp of the code, to browse the code efficiently, and to understand why a certain functionality is implemented in that way. However, I really learned and enjoyed reading, and challenging myself into understanding certain aspects of the code on my own, and I feel that this skill has really improved since then.

Since gitg is a git client application, so of course it’ll improve my “git” skills, also I’ve been learned more about Flatpak Packaging and the Meson Build System.

Overall it was an eye-opening experience, where I learnt a lot and it was really a great opportunity to see and learn how professional open-source applications are being developed.