Gitless works around Git’s problems, simplifies programmers’ life
Pragmatic or get organized concept image via Shutterstock
Meet Gitless, an experimental version control system built on top of Git by a team from MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL). In short, Gitless promises to solve some of Git’s core issues and help ease programmers’ work.
Git’s reputation among programmers is outstanding but this does not mean everything goes smoothly. According to the official page of Gitless, “many people complain that Git is hard to use” — hence the need for this experimental version control system built on top of Git (which means you can fall back on Git if you should decide that Gitless is not for you).
MIT graduate student Santiago Perez De Rosso, who co-wrote a related paper with MIT Professor Daniel Jackson, revealed that Gitless is “easier to learn and use (than Git) and still keeps the core elements that make Git popular.” The idea behind this interface is to fix some of Git’s core issues without fundamentally altering its main purpose.
As the official announcement shows, this experiment was partly created by analyzing almost 2,400 Git-related questions from StackOverflow. The team pinpointed some of Git’s biggest problems and tried to minimize them. One of the best things about Gitless is that it is implemented on top of Git, which means programmers can switch between them without having to migrate code from one to the other.
Gitless eliminates “staging,” which allows programmers to save just parts of a file and commit finished changes while maintaining the unfinished changes as a work-in-progress. Still, the consequence of having both a staged and working version is that “if you stage a file and make more changes that you then commit, the version that’s committed is the one you staged before, not the one you’re working on now.”
In short, Gitless hides the staging area, thus making the process less complicated for the user. You can still select parts of code to commit thanks to the more flexible “commit” command.
“Stashing” is also gone. According to De Rosso, when a programmer switches branches, they may or may not remember “which stash goes where.” It becomes an even bigger problem if “you are in the middle of an action like a merge that involves conflicting files,” the graduate student explained. Gitless makes branches independent from each other so that developers who must constantly switch between tasks have a clear picture of what they have to do.
Git vs Gitless
The team from MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) also conducted a user study to see how well Gitless performs when compared with Git. The study shows that saving changes to the repository is very straightforward with Gitless. Plus, the classification of any file can be changed to tracked, untracked or ignored no matter if the file exists at head or not.
In Gitless, uncommitted changes do not conflict with the modifications in the destination branch.
In a post-task survey, participants stated that Gitless’ ability to transition between branches is “very smooth” and “way more intuitive.” De Rosso pointed out that participants were skilled in Git and opined that results could have been even more obvious if people with no Git experience participated in the survey. The team’s work indicates that “the same approach might be used to improve the usability of other software systems, such as Dropbox and Google Inbox.”
Read here the paper What’s Wrong with Git? A Conceptual Design Analysis by S. Perez De Rosso and D. Jackson.