Git Case Study
Project Background:
Git is unusual among major software projects because it is still fundamentally mailing list-based: patches are proposed as email threads, reviewed in public on the list, revised as new versions, and then promoted through branches like seen, next, and master rather than being merged directly from GitHub.
That workflow matters here because the work was not on a trendy front-end surface. It was on gitweb, Git's long-lived browser interface for viewing repositories, logs, trees, commits, and diffs. It is long-lived legacy infrastructure, seemingly close to maintenance mode, which meant a carefully scoped, non-disruptive mobile improvement was the kind of change most likely to land.
How The Problem Surfaced:
The problem first surfaced while browsing the FFmpeg repository on a phone. FFmpeg was being hosted through Git's legacy gitweb, and the interface was still clearly desktop-first. Reading the source tree on mobile turned into a literal "panzoom dance": two-handed pinch-zooming and panning around the page just to read each line.
Because FFmpeg was downstream of Git's own gitweb, the right fix was upstream. Instead of patching a single hosted instance, Rito decided to improve gitweb itself so the change would flow to any project still depending on it.
Entering The Workflow:
Since the fixes were visual, before-and-after screenshots were important. That made GitGitGadget the most convenient bridge into Git's mailing-list process because it let the patch series live on GitHub to host the images while still being submitted properly to the list.
It was Rito's first time contributing through that workflow. He joined the #git-devel IRC channel, asked to be allowlisted to use the tool, and someone quickly jumped in to do it. The GitGitGadget bridge PR was then submitted to the mailing list on February 9, 2026.
The Patch Series:
The contribution landed as a five-patch series of targeted fixes. It started with the viewport meta tag in Perl so gitweb pages would actually honor the mobile viewport, then layered in CSS changes that respected the existing desktop structure instead of redesigning it.
The strategy was adaptive rather than transformative: keep the legacy desktop layout intact, but add mobile constraints so page headers could expand, long content could wrap instead of blowing out the viewport, and wide tables could scroll within their own containers rather than forcing page-level overflow.
Sidequest: Improving The Bridge Itself:
While the gitweb patches were moving through review, Rito ended up improving the GitGitGadget website itself. The site had the same desktop-first mobile problems as gitweb, so he made it responsive in PR #26, then followed with a favicon PR, canonical tags for SEO, and a footer/navigation pass, and custom 404 page handling so the site was no longer orphaned.
Those changes were reviewed and merged by Git for Windows maintainer Johannes Schindelin. He liked the mobile work, but pushed for more explicit commit bodies when the reasoning was not as obvious to other readers as it was to the person writing the CSS. Rito rewrote the commit messages to better explain why each change was correct.
After Rito expanded the commit bodies, Johannes Schindelin merged the series and said:
"The love and care you put into them clearly shows and I appreciate it a lot. The comment messages now tell a really compelling story, are pleasant to read, and I am super happy to merge it. Thank you so much!"
Review, Revision, And Merge:
Git's review cycle was fast but real. Eric Sunshine thought the overall direction made sense, but he also spotted a flaw in how one of the commits told the story of the changes. Rito reworked the sequencing, made the v2 patch flow clearer, and resubmitted.
From there the series moved through Git's normal pipeline: first into seen, then into the status updates where Junio C Hamano summarized it as "gitweb" has been taught to be mobile friendly, then onward through next and master. Eric later said v2 made more sense than v1 and that the changes overall made sense.
The final upstream merge landed on March 4, 2026 in commit bcc2fc2. The whole series landed in under a month, which is a strong turnaround for a first contribution moving through Git's full mailing-list review process.
