Once again about “Mercurial vs. Git” (with pictures)
Some time ago I published a very verbose essay where I tried to explain why Git is seriously broken, and why everyone should use Mercurial instead, until the Git developers have fixed it. Well, okay, I wasn't so rude, but close to that.
The people at Reddit complained that my technical language was too confused, especially because I was inventing new terminology in an attempt to prove my points. They demanded graphs, with nodes, edges, circles, arrows and all the rest. Then I tormented the graphics editor for several hours and got two graphs below, with which I hope to outline the problem.
Below, I have drawn a simplified graph of the history of the Git repository with three branches created: “master”, “release” and “topic”. Before Git enthusiasts start swearing that I contrived to show an unrealistically bad case of history confusion, let me assure you that this is actually a simplified example. I have access to the real Git repository, where six working release branches, about forty working thematic branches, and several hundred previously existing branches that have already been removed from the central server have been created.
Here is the graph. Can you tell me on which branch the change of
')
I know it's not fair. I do not show you a change log. But trust me, you do not want to see him. He will not help. You think domesticated primates [1] wrote useful tips there that would answer these questions, but they did not. Worse, sometimes they lie.
A smarter refutation of my questions would be to ask, “Why do you need to know this?” Let me answer this consistently.
Mercurial users, in most cases, do not need such unnatural coercion. And that's why:
See the difference?
Each node in the graph is colored to show the name of its branch in Mercurial. Every guessing game becomes unnecessary. You firmly know that once there was a branch called “temp”, which then joined the “release” branch, not the “master”. Probably now it is marked closed, no longer needed.
Some initial work on the topic branch went into the temp branch before merging with the release branch. Later, the “release” branch was back merged into the newly introduced “topic” branch.
All this is possible because Mercurial stores the name of the branch in the header of each change. Git should do this too, but does not. Instead, Git encourages users to fake a story as if it were “clean,” but in reality is unsightly.
The saddest thing is that most Git users seem to have a conceptual block against even acknowledging that there is a problem. They accept the need for such historical revisionism, which their tool imposes on them, and call it dignity.
I’m afraid of the prospect of transferring the source code base of some large and respectable proprietary operating system from the old inherited version control system to the new cool distributed system that all the guys are talking about. I predict that I will have to show this blog post to so many people.
[1] Domestic primates are probably a reference to Timothy Leary or Robert Anton Wilson - approx. trans.
The people at Reddit complained that my technical language was too confused, especially because I was inventing new terminology in an attempt to prove my points. They demanded graphs, with nodes, edges, circles, arrows and all the rest. Then I tormented the graphics editor for several hours and got two graphs below, with which I hope to outline the problem.
Below, I have drawn a simplified graph of the history of the Git repository with three branches created: “master”, “release” and “topic”. Before Git enthusiasts start swearing that I contrived to show an unrealistically bad case of history confusion, let me assure you that this is actually a simplified example. I have access to the real Git repository, where six working release branches, about forty working thematic branches, and several hundred previously existing branches that have already been removed from the central server have been created.
Here is the graph. Can you tell me on which branch the change of
ab3e2afd was fixed? What was the earliest change on the release branch? Where exactly did the topic thread start?')
I know it's not fair. I do not show you a change log. But trust me, you do not want to see him. He will not help. You think domesticated primates [1] wrote useful tips there that would answer these questions, but they did not. Worse, sometimes they lie.
A smarter refutation of my questions would be to ask, “Why do you need to know this?” Let me answer this consistently.
- I need to know on which branch
ab3e2afdwas fixed in order to know whether to include it in the description of changes in the future release. - I need to know what change was the first in the “release” branch, because I want to start a new thematic branch with this change as a starting point so that I am always aware of what is happening in the main branch as much as possible, and be sure that I can perform a clean merge into the main branch and release a release.
- I need to know where the topic branch has started so that I can put all the patches together and send them to my colleagues for review.
Mercurial users, in most cases, do not need such unnatural coercion. And that's why:
See the difference?
Each node in the graph is colored to show the name of its branch in Mercurial. Every guessing game becomes unnecessary. You firmly know that once there was a branch called “temp”, which then joined the “release” branch, not the “master”. Probably now it is marked closed, no longer needed.
Some initial work on the topic branch went into the temp branch before merging with the release branch. Later, the “release” branch was back merged into the newly introduced “topic” branch.
All this is possible because Mercurial stores the name of the branch in the header of each change. Git should do this too, but does not. Instead, Git encourages users to fake a story as if it were “clean,” but in reality is unsightly.
The saddest thing is that most Git users seem to have a conceptual block against even acknowledging that there is a problem. They accept the need for such historical revisionism, which their tool imposes on them, and call it dignity.
I’m afraid of the prospect of transferring the source code base of some large and respectable proprietary operating system from the old inherited version control system to the new cool distributed system that all the guys are talking about. I predict that I will have to show this blog post to so many people.
[1] Domestic primates are probably a reference to Timothy Leary or Robert Anton Wilson - approx. trans.
Source: https://habr.com/ru/post/123700/
All Articles