Git for design projects

Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

At Libre Graphics Meeting 2016 in London, Julien Deswaef presented a talk exploring how Git can aid graphic designers and other artists in their daily processes, as well as pinpointing Git's shortcomings for that user community. The crux of the issue is that, for Git to be useful for visual design, it would need to provide ways for users to inspect and compare changes to media files as media, not as raw data. That is, to provide "visual diff."

Deswaef talks to a lot of designers, and an increasing number are familiar with Git and GitHub (although they are not always clear on the distinction between the two), but they rarely take advantage of it. Most design applications today provide their own file versioning, but of a rather limiting form, such as simply saving multiple local copies of a project file with numbers tacked somewhere onto the file name. Essentially no design tools implement anything close to Git's more advanced features like branching, even though they would be just as useful for design as for code.

The question of how to convince designers to use modern version-control tools like Git has been brewing in the back of his mind for some time, Deswaef said. At LGM 2013 in Madrid, he reminded the audience, he had presented a demo of his first "design with Git" experiment, which provided a "visual diff" for SVG files kept in a Git repository. The goal was to make tracking changes in a graphics file as convenient as it is for text, and he implemented a variety of visualization options, getting positive responses from designers. But his efforts to get companies that provide Git services (like GitHub) interested in the tool proved fruitless.

Last year, he said, he found himself living in a new country and with excessive free time, so he revisited the question—first, by cataloging all of the similar work he could find that is already used by designers. Some designers work with "digital asset management" (DAM) systems, although "if you don't work in a 500-person company, you probably don't have access to one." Then there are the web-based software services. Some of the most popular are targeted at specific sub-disciplines, like InVision and Pics.io for interaction design. There is a service called Gravit that lets users fork and remix projects; ironically, it used to be open-source software, then it was taken proprietary. Another, LayerVault, went bankrupt. Its closest competitor, Pixelapse, is still around, but was purchased by Dropbox (which Pixelapse had used as its storage back-end) and has stopped receiving updates. Not that the loss is great, he added: Dropbox's idea of versioning is just appending numbers onto the name of the file.

In practice, though, the market leader is Adobe's cloud service, which he described as "Adobe Captive Cloud;" it is a Dropbox clone that comes built into Adobe's desktop applications. But even then, it is a terrible versioning tool, he said. For starters, it treats every file format other than Photoshop's PSD as an opaque binary, giving the user no previews or thumbnails. Worse still, as the fine print reveals, the service may look like a folder on your desktop, but it actually only retains copies of files for ten days, then it deletes them. "Who wants to access something they worked on more than ten days ago?" he joked. "Nobody, I guess."

But if it seems like the proprietary offerings are not serving designers well, the free-software world is not doing much better. Anecdotally, it seemed clear that many designers and other Git users store image and media files in GitHub, so Deswaef decided to get a clearer picture of how common the practice is. Using the site API, he spent several weeks querying public projects hosted on the site, retrieving each project's file listings and logging the file types in a database.

He sampled one percent of GitHub's available projects altogether: 500,000 projects (including forks), which contained about 130 million files. Of those, he said, about 12% are some form of media. More than half of the media files are PNG images, followed by JPEG and GIF at around 14% each. About 9% of the media files fell into the "other" category, which included everything from PDF to font files to audio to 3D formats like OBJ. What stood out, though, was that many of those media formats are directly viewable in browsers, but GitHub does not display them. For example, "GitHub likes to promote that people use it for font design," he said, pointing to the site's promotional material, "but it's not helping them." A few rather arbitrary formats are displayed directly. The site renders STL files (for 3D printing) to WebGL, but does not do the same for OBJ, which is five times more popular.

Alternative GitHub-like offerings such as GitLab offer the same story, but with the added drawback of not being nearly as popular of a service. Self-hosting a package like Gogs is a non-starter for most users who are not experienced with server administration. There is one free-software Git system familiar to many in the LGM community, he said: visualculture, which is the project-publishing front-end used by the non-profit Open Source Publishing (OSP) project, many members of which are long-time LGM presenters and active free-software developers. But visualculture is highly customized to tie into OSP's internal structure and release processes. While it provides visual display of many types of media, it omits other features like issue tracking, and Deswaef said he was unable to get anything more than the home page running on his own machine.

One might consider telling designers to use Git locally, he said, except that doing so with any sort of visual diff means providing a GUI front-end. And writing a usable desktop front-end for Git still seems to elude developers—although not for lack of trying. "There are as many Git GUIs as there are people upset about Git GUIs," he noted. A few standalone tools for "visual diffing" do exist, he said. P4Merge is freeware, and does not even come with an end-user license agreement (EULA), which is a whole other issue on it's own, he said. There is also webdiff, although it only presents side-by-side views of the changed file, which turns the diff process into more of a "can you spot the changes" puzzle than anything else.

He concluded by turning the questions back to the audience. "Where is my open-source Git desktop?" We have isolated web tools that need further polish, he continued; is that the future? Deswaef said he maintains a growing list of bookmarked projects that might prove helpful for designers who want to use Git. For most of the media files that GitHub cannot render directly in the browser, there is some open-source project that could provide a solution, such as three.js, a JavaScript library to transform OBJ and other 3D file formats into WebGL. But it remains up to GitHub or other services to deploy solutions of that nature.

In the question-and-answer period at the end of the session, one audience member asked if perhaps designers needed to be more open and embrace other kinds of software interfaces. Deswaef replied that he does not think giving up on visual diff is necessary. "There are a lot of people interested in this problem; big companies as well as small shops. But everyone is waiting for someone else to find the recipe that will fix the whole thing."

Eric Schrijver from OSP also spoke up, first concurring with Deswaef's assessment of the visualculture tool. "We have tried finding funds to do the work of un-tying it from us," he said, but without success. He then asked whether Git was truly a good fit for design projects, considering that the workflow of an artist or design team can be so variable, depending on the project and the participants. Deswaef replied that he did not think that was an impediment. "Git supports thousands of different workflows already," he said. Schrijver then asked whether it might be worth setting an attainable goal, like "let's implement media-file display in GitLab by LGM 2017."

Deswaef did not object to that idea, but he re-emphasized the importance of GitHub. The company has already done work to standardize project presentation, such as making Markdown-formatted README files the entry point, he said, and it has rolled in other features like GitHub pages, issues, and announcements. "What I want to see is something that you can set up for your project when you don't know in advance who you will be collaborating with." Realistically, a self-hosted solution likely does not fit that bill, given that so many designers already have trouble distinguishing between Git, the tool, and GitHub, the service.

Discussion on the subject continued well after the session was over, as one might expect at a free-software event filled with artists and designers. There is clearly a lot of room for improvement in how Git tools and services handle media files. Whether GitHub takes the hint or someone else from the free-software development community beats the company to the punch remains an open question.

[The author would like to thank Libre Graphics Meeting for travel assistance to London for LGM 2016.]