Made in MIT: Gitless version control system

You all know the git system. At least heard - this is for sure. Developers who use the system, or love it, or blamed for a complex interface and bugs. Git de facto version control system is the industry standard. A developer may have opinions about the advantages of Mercurial, but most often you have to put up with the requirement to be able to use Git. Like any complex system, it has many useful and necessary functions. However, not everyone gets to the ingenious simplicity, so the existing implementation left room for improvement.

Simple words - tricky application was difficult to use. Therefore, in the laboratory of the Massachusetts Institute of Technology, they took up the improvements and cut off all the “problem elements” (after all, that for one problem, for another it can easily be an advantage). An improved and simplified version called Gitless. It was developed taking into account 2400 issues related to Git and taken from the developer site StackOverflow.

The team of authors has isolated the most problematic places in Git, including two concepts of staging and stashing. They then proposed changes designed to solve known problems.

Whats wrong with git

Many users complained that Git needs a new interface. Experts even compiled a document. What is wrong with Git? Conceptual analysis of the design. Authors: S. Perez De Rosso and D. Jackson.
')

Example

git checkout < file > //            git reset --hard //            

These two lines are one of the illustrations of how much Git needed an improved interface. Two different commands for one function with one difference is that one for a single file, and the second for multiple files. Part of the problem is also that these two teams don't actually do exactly the same thing.

Most Git users use it for a small number of commands, and the remaining units know the platform at a deeper level. It turns out that basically the platform is needed for basic functions, and a large layer of possibilities remains for too narrow a circle. This indicates a git malfunction.

A brief comparison of the basic functions with the previous version

One of the highlights of Gitless is that the version ignores a feature called staging. It allows you to save individual parts of the file. Convenient, but can create problem situations. The key difference between this and the stashing function is that the second one hides the changes from the work area.

The stashing function hides the rough work in the working directory — monitored files that have been changed and saves everything to the stack with pending changes. All changes can be applied later when it is convenient. This is necessary when you are working in one branch and everything is in a messy state, and you urgently need to switch to another branch. You do not want to unload code with partially done work in the first branch for the duration of the pause.

The staging function indexes changes made to a file. If you have marked staged files, Git understands that you have prepared them for upload.

Gitless has no stashing concept. Imagine the following situation. You are in the midst of a project development and have to switch to another branch of it, but you have not yet uploaded your half completed work to the system. The stashing function takes the changes you have made and saves them to the stack with unfinished changes that you can restore later.

The author of the Gitless tutorial reports that the problem occurs when switching between branches. It can be difficult to memorize which stashes where it is located. Well, the pinnacle of all this was that the function does not help in the case when you are in the process of merge, which includes conflicting files. This is the opinion of Perez de Rosso.

Thanks to Gitless this problem is solved. The branches became completely autonomous in relation to each other. This makes work much easier and allows developers to avoid confusion when you need to constantly switch between tasks.

Saving changes

Gitless hides the stage area as a whole, which makes the process more transparent and less difficult for the user. There are much more flexible “commit” commands to solve problems. And they will allow to do such actions as selection of code segments for a commit.



In addition, you can change the classification of any file to values: monitored, not monitored, or ignored. It does not matter whether this file exists in the header or not.

Branching development processes

The basic idea for understanding the new version: the branches in Gitless have become completely independent lines of development. Each of them remains with its working version of the files separately from the others. Intersections and no problems. At whatever point you switch to another branch, the contents of your workspace are saved and files that are related to the destination branch are restored. File classification is also preserved. If the file is classified differently in two separate branches, then Gitless will take this into account.



Simply put, in the Gitless version you don’t need to remember about unloaded changes to the system that are in conflict with changes in the destination branch.



You can also postpone the resolution of a conflict situation if you have the middle of a merge or fuse. The conflict will remain until you switch back.

Work with remote repositories

Here synchronization with other repositories is the same in both programs.



Another advantage of the new version is the ability to switch to the old one without losing the code. In this case, your colleagues may not even be aware that you are using other software.

You can learn how to use Gitless on the official website of the application. The documentation describes the following: how to create a repository, save changes; how to work with branches; how to use tags, work with remote repositories.

What is the result

It turned out an application that preserves the functionality of Git, but at the same time it has become easier to learn and use by the development teams. In fact, even before Gitless, there have already been attempts to improve Git. But according to Philip Guo (he is an assistant professor of cognitive science at the University of California San Diego), this version for the first time reached the goal of transforming the interface and actually solving the main problems.

The project used rigorous methods for creating software. This is necessary to isolate shortcomings in one of the most widely used software projects worldwide. In the past, many users gave ridiculous arguments both for and against Git, but all of them were not based on a scientific approach.

Using Gitless as an example, it becomes obvious that the simplification approach can be applied to other complex systems. For example, Google Inbox and Dropbox.