Why I don’t dislike Git: hidden integrity

I bring to your attention the translation of a small article from the blog of Armin Ronacher - author Flask, Jinja2 and much more. This time, he will share his thoughts on Git, the distributed version control system for files.

Git is an interesting topic for me. I first tried using Git when there was no command system at all, and Cogito was considered a promising project. I can not say that I liked it, at that time I mainly used SVN, and it completely solved all my tasks. Soon I met Mercurial, and it was love at first sight, which marked the beginning of a long and positive experience of using this VCS (version control system), which I received in my person a loyal supporter. It was only in 2008 that I switched to Git, and it took me a few tries before I realized that it was time to transfer my repositories to it.
')

Git's awesome command system

I suspect that a developer who has upgraded to Git from any other version control system will be unpleasantly surprised by the lack of integrity in his commands. Steve Losh was not even too lazy to beat it in his " Git koans ".

However, every time this topic is discussed again, I feel a little bewildered because I can't remember any problems with the Git commands in my daily work. Of course, the git remove syntax is different from the git branch and git tag, but I use them for different tasks without even thinking about inconsistency. The only strange command I remember is “git show”: its syntax for displaying the contents of an object every time is puzzling.

But about Mercurial and Perforce, I can easily recall the frequent struggles in performing normal, routine operations - which can't be said about Git. Why doesn't the Git command system cause me so much dislike?

Learning vs. teams study ideas

While thinking about this issue, I came to the conclusion that the reason for such an easy adoption of Git syntax is the principles of its learning by programmers. In the case of Mercurial and Perforce, the developer masters a set of command line spells to solve specific problems, and everything that is “under the hood” is omitted.

And for Git, the opposite is true: from the first pages of the reader’s introduction, they refer to the description of the insides of this VCS , which details what and how it works.

This method of learning went back to the times when Git had no command system at all. It was expected that the developer will manually edit the files in the ".git" directory! I remember my first experiments with this system when the commit: .git/HEAD command did not even exist, but only the symlink to the current branch, and the documented way of the commit was:

echo "Commit message" | git-commit-tree $(git-write-tree) > .git/HEAD

Only after a while, the “commit” operation was allocated to the command, but even then the instruction on its use was ... just like that .

Git was not originally designed as VCS: it was created as an idea that other software can use to create a VCS. And this fundamentally distinguishes the Git development process from the way all other version control systems were developed.

Of course, over the past 10 years, Git has changed a lot, and some of the ideas at its core have changed, but the main point has not been transformed much. And there is a certain beauty in creating a repository using Git 2005, then committing using the same version, and then watching the log using Git 2015.

Of course, to work with Git will have to learn not the simplest system of commands, but the basic ideas underlying this VCS are worth it.

Good default behavior

The system of Git commands, admittedly, is not the best possible, but they are equipped with good default behavior, which only improves every year. Behavior of Git "out of the box" adequately, the most popular methods of work correspond to the settings of the teams, and when this is not so - you can count on an open discussion. For most tasks, there is an “approved” way to perform them with Git, and this method is usually easy to learn. Working with branches in Git has not changed since its inception, and the knowledge gained 10 years ago is still relevant.

Good architecture

I believe that Linus, when creating Git, came up with a damn good architecture for him, which required a minimal amount of changes in the future. As time has shown, work with commits and objects was implemented correctly, as well as the mechanism for working with branches. Even Mercurial has given up and now warns the user that creating a named branch is not the best idea.

Having studied the basic concepts underlying Git, I can safely use the full breadth of its tools. Of course, sometimes you have to climb into Google to refresh some rare commands in your memory, but such a need almost does not arise in everyday work. I have never had a chance for me to break the repository and I could not fix everything.

The Git command system is devoid of integrity and simplicity, but its architecture has both of these qualities, and for that I value Git.

Git is on my side

One of the reasons why I forgive Git is his system of commands and sometimes uncomfortable behavior: he always plays on my side. Many times I broke the repository in a monstrous way, doing the wrong merdzhi and erasing the wrong data, but there was never a case that the data would be lost or the VCS would leave me alone with the ruins.

In case of problems, I sometimes make a copy of my “.git” directory and then, in retrospect, I study what I did wrong. Situations where recovery is impossible are extremely rare - and this is one of the options where Git unlocks its full potential. I still remember my mistakes with other version control systems that blew up the repository and made it impossible to recover without the participation of the developers of these VCSs.

In my memory, there was not a single case of a broken repository due to incorrect use of Git or because of its internal work, whereas with other VCS I have the sad experience of broken working copies of Subversion, destroyed servers, broken Perforce vaultsspaces and damaged Mercurial repositories by my hands.

The worst thing that happened to me with Git is the incorrect permissions for a number of files in the Flask repository, caused by the GitHub bug.

Conclusion

I think, I would not refuse, that such software as Git, was more. Software, where the internal logic of the work is an important part of its interaction with the user, and the user interface is not separated from the black box implementation.

A counter example of such software can serve as a cognitive separation that arises between me and the latest Apple software solutions. There is no longer a “save as” window, and the “save” dialog now often shows a delete button, even if nothing has yet been saved to the file system. Too often, I have overwritten presentations in Keynote because the file system logic and the user interface logic are completely different. It saddens me when fundamentally different operations (discard of data that has not yet been saved and erasing a file already stored in the file system) are called and look the same.

From translator

It will be possible to talk with the author of the article and other notable Pythonists this Friday, March 20, in St. Petersburg at the PiterPy conference, to which we invited them :) Experts Alexander will also be speaking at the event, which Positive Technologies supports as a general sponsor. Koshkin and Ivan Tsyganov, and its leading developer Sergey Matveyenko will become the lead of one of the streams.

Translation: Grigory Petrov (@eyeofhell)