Santiago Perez De Rosso, a PhD student in the Software Design Group at MIT’s Computer Science and Artificial Intelligence Laboratory, talks about Gitless—a kinder, gentler form of version control software.
1. You recently published a paper describing a new programming tool called Gitless. What led you to develop it?
My research involves developing techniques, tools, and theory to make software, and the process of software engineering, better. Much of that work involves writing code. And being able to keep track of the changes made to source code—a process called version control—is a very important aspect of software development.
One of the most popular version control tools is Git. Git is exceptionally complicated. But we do not believe that complexity is inevitable: Git could be made simpler by reworking the tool’s underlying concepts, an idea we explored in Gitless.
2. How does Gitless solve those problems?
Gitless is Git, reimagined. Like Git, Gitless enables you to manage changes to files, and has convenient features such as fast creation and merging of branches. But Gitless is much easier to learn and use: You can read a single page worth of documentation and be ready to go. This means you can focus on your work instead of wasting time fighting with version control.
Take, for example, “branching.” In Git, branches let you duplicate files so that they can be modified in parallel along each branch, for instance to develop new features. But actually switching branches is sometimes difficult because, although branches are maintained separately in the Git repository, there is only one virtual location in which changes can be made—the so-called ‘working directory’. Thus, before you can switch branches, your coding changes must be reconciled with the stored code base, a process that can fail if multiple programmers are accessing the repository such that their individual changes conflict with one another.
In Gitless, branches are completely independent, providing each branch, in effect, its own working directory. When switching from branch to branch, Gitless takes care of saving the uncommitted changes you had in the first branch and resurfacing them when you return. This means you can always switch to another branch, even if you are in the middle of the process of merging two branches.
Gitless also has no staging area (an intermediate area where code changes can be formatted), which greatly reduces the complexity associated with committing file changes to the repository. And there is no need to explicitly add files to track: You just use our flexible ‘commit’ command to select those changes you want to commit, whether it’s just a subset of the modified files or a few individual changes per file.
3. Can researchers who already work with Git and/or GitHub use Gitless?
Yes! Since Gitless is built on top of Git, every Gitless repository is a Git repository and vice versa. This means that you can seamlessly switch between Gitless and Git and continue using GitHub. And, your collaborators need never know you’re using Gitless.
4. How can interested researchers get started?
Gitless binary releases are available for Mac OS and Linux, and since June 2016, they have been downloaded more than 1,400 times. (Windows is not yet supported.) You can also install the software from source code, through Python’s package manager, or using the homebrew tool. For installation instructions and documentation, visit gitless.com.
Jeffrey Perkel is Technology Editor, Nature.