The current status of the tools. User view

Warning: This article will not teach you anything. This is a very high-level view, my thoughts, my reflection on a question that is important to me + a small ethnographic research on graphic clients of git.

Let's talk about distributed version control systems.

CVS was sad, slow, non-atomic ("don't touch anything, I'm commuting"), but with a normal client in Eclipse.
')
SVN was slow and fun at first, but with the advent of the first branch, it was also sad (“do not commit anything, I am angry”), with two different clients in Eclipse, the bugs of which gently complemented each other.

Then I learned git. Git is such an illogical set of command line utilities in which daily operations are performed by a sequence of two to four commands. The first week I poked in every corner, like a blind puppy. I drew myself a diagram of four repositories (working copy, staging area, local repo, remote repo), and signed with arrows what command and with what options it transfers information from where to where. By the end of this period of adaptation, I found the cherished combinations that I needed in everyday work, and gained some courage in shuffling the instruction set with a piece of paper, forcing them to give out more or less what I needed. The power of an interactive commit from the command line, or, say, what requests to make in order to understand the current state, I have not yet mastered. I was pleased that the repository can be rotated as you like, you can re-associate anything with anything, however, the magic needs the appropriate one for this.

I recently met with Mercurial - here I didn’t even try to learn anything, immediately set up a graphical client, regretted my brain. I read how their history is being rewritten to make a commit amend - this is a ritual with three half-hour spells and one "extension" (the extension's installation is that you prescribe its name in the config file - like before Mercurial knew nothing about it, but now I found out). Examine both of these tools at the same time - well, I do not know who to be:



“Why am I doing this?” Asks an impatient reader. The threshold for entry into the RCAM (DVCS) is high. Many do not use them, not because they think that they do not need it, but because it is actually difficult. Including programmers, who are mostly people too. The creators themselves pay more attention to the internal device than to the command interface - well, so where are the third-party developers, where are the enthusiasts? Such a complex thing, like managing a repository, directly asks, well, the graphical client suggests itself! There are a lot of them. I looked at the Makovsky sector - it would seem that people should do it.

The first sad fact is that the overwhelming number of clients know only what to show the tree and commit. This is already something - you can at least understand the state of the repository, but otherwise means that a little bit beyond the bounds of the straightforward history of commits you will again be alone with the command line.

The second sad fact is that they can’t even show the tree normally - although, it would seem, well, if your program has two functions, well, at least they have loosened them thoroughly.

For example, the old gitk put a lot of effort to confuse its user:



This approach is justified in the case of Windows and Linux (and how else to sell support?), But it raises questions.

To date, (1.7.3.5) gitk has been corrected a little, but the picture is still not conducive to reading information - the colors are distributed according to an incomprehensible algorithm and in general distract, the inscriptions are not aligned, which makes scanning difficult:



But! The most interesting thing is that they did not stop there. By default, gitk shows the story in ... drum roll ... confused look! This is what they call a "lax story" or something like that. I shake my hand, I guess. This is supposed to simplify perception:



And, characteristically, the example was picked up (about this, see also the third sad fact). Here, for example, the pretentious Tower , which the tree doesn’t like to draw at all (I didn’t even find it right away - usually it’s just there a list of commits the size of a half-screen a la github):



Here is gitx , not so pretentious and really with two functions. They, like the authors of gitk, decided to save a dozen or two pixels on the left edge to the detriment of readability. Both gitx and the previous Tower tree of the “strict” history are generally refused to show.



But egit , Eclipse plugin, for which it’s not just a tree, for him the inscription is unpleasant to draw a problem. I was ready for this, but with his original vision he surprised me:



Unexpectedly, SourceTree performed well. The tree he has is not without self-intersections, but the essence of what is happening is not hidden behind the mash-up of circles and lines.



I like it very much, but experience has shown that, for example, it is impossible to create a merge from it. Therefore, only for stupid tasks. But it can and git, and Mercurial, does not ask unnecessary questions (where did you install the distribution kit git-a?), But it provides the correct (name and email for commits).

I even made my own version of this tree out of interest:



The colors are removed, there are no self-intersections, the colors are highlighted, because these are not full-fledged commits (in fact, not in terms of implementation) - this is all I came up with useful. If someone can advise something else - I will be glad.

And finally, the third sad fact. There are customers who can do a little more - probably, they have reached their hands, they have had time. But their “advanced” functionality is the same set of console utilities, for which there are just buttons in the interface.



For some reason, no one thought of the simple idea that, based on the constructor, the API, which is git and hg, you can and should make a convenient, simple and intuitive interface with new metaphors, actions, capabilities; interface that removes flaws, not repeats them; but every once in a while they repeat the fact that the authors of the console interface were riveted on impotence. I insist that today's RSUV are not ready-to-use products, but platforms that are just waiting for their product.