Why I Don't Dislike Git: Hidden Integrity

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

Git is an interesting topic for me. I first tried using Git when there was no command system at all, and Cogitowas considered a promising project. I can’t say that I liked it, at that time I mainly used SVN, and it completely solved all my problems. Soon I met Mercurial, and it was love at first sight, which laid the foundation for a long and positive experience in using this VCS (version control system), which got a loyal supporter in my face. It was not until 2008 that I switched to Git, and it took me several attempts before I realized that it was time to migrate my repositories to it.

Monstrous Git Command System

I suspect that a developer who switched to Git from any other version control system will be unpleasantly surprised by the lack of integrity in his teams. Steve Losh was not too lazy to beat this in his “ Git Koans ”.

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

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

Learning teams vs. Learning Ideas

Thinking over this question, I came to the conclusion that the reason for such an easy adoption of the Git syntax is the principles of its study by programmers. In the case of Mercurial and Perforce, the developer masters a set of command-line spells for solving specific tasks, and everything that is “under the hood” is omitted.

And for Git, the opposite is true: from the first pages of the introduction, the reader is referred to the description of the internals of this VCS , which details what and how it works.

This training method has gone back to the time when Git did not have a 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 command did not even exist:.git/HEAD, but only a symlink to the current branch, and the documented method of committing 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 for its use was ... like this .

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

Of course, over the past 10 years, Git has changed a lot, and some of the ideas in its basis have changed, but the main essence has not changed much. And there is some 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 you will have to learn not the simplest command system, but the basic ideas that underlie this VCS are worth it.

Good default behavior

The Git command system, admittedly, is not the best possible, but they are equipped with good default behavior, which only improves every year. The behavior of Git “out of the box” is adequate, 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 accomplish them using Git, and this method is usually easy to learn. Work 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 he created Git, came up with a damn good architecture for him, which required a minimal amount of change in the future. As time has shown, working 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 a good 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 teams, but such a need hardly arises in everyday work. I have never had the occasion that I broke the repository and I could not fix everything.

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

Git by my side

One of the reasons why I forgive Git for his command system and in some places uncomfortable behavior: he always plays by my side. Many times I broke the repository in a monstrous way, making incorrect merges and erasing the wrong data, but there was never a case when the data was lost or 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, examine what I did wrong. Situations when recovery is not possible are extremely rare - and this is one of the options where Git fully reveals its potential. I still remember my mistakes with other version control systems that blew up the repository and made it impossible to restore it without the participation of the developers of these VCS.

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

The worst thing that happened to me with Git was the incorrect permissions for a number of files in the Flask repository that arose due to a GitHub bug.

Conclusion

I think I wouldn’t refuse to have more software like Git. Software, where the internal logic of work is an important part of its interaction with the user, and the user interface is not separated from the black box implementation.

A counterexample of such software is the 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 displays a delete button, even if nothing has been saved to the file system. Too often, I rewrote presentations in Keynote because the logic of the file system and the logic of the user interface are fundamentally different. It upsets me when fundamentally different operations (discard data that has not yet been saved and erasing a file already saved in the file system) are named and look the same.

From translator

You can chat with the author of the article and other notable pythonists this Friday, March 20, in St. Petersburg as part of the PiterPy conference , to which we invited them :) At the event, which Positive Technologies supports as the general sponsor, Alexander company experts will also speak Koshkin and Ivan Tsyganov, and its lead developer Sergey Matveenko will become the leader of one of the streams.

Translation: Grigory Petrov (@eyeofhell)