It's not just that the mere fact of being able to manipulate the myriads of git commands with ease confers substantial bragging rights, but it really is the fact that git allows developers to present a more polished image of their work.Git makes developers look good.
Let's compare the typical work flow:
In both systems, you start by cloning some repository, and begin work:
Usually, it will take several tries to get your work done, and the checkin comments above are quite typical - the ones shown are safe for work.
Meanwhile, some other changes happen on the main line, and you being a good citizen, pull in the changes.
And here is where the two systems differ: In mercurial, you merge:
... and that's it. The owner of the parent repo pulls in your change, and all your dirty laundry is visible to the public, exposing you to various forms of ridicule:
Git gives you, the developer, much more control over your image. For one, you probably won't merge, but rebase. This keeps the revision history linear, and gives the warm fuzzies to those who hate revision graphs.
The next thing you do is use the interactive rebase to squash all those embarrassing mistakes, and make it appear as if perfect code flows right off your fingers.
The final result is that git will usually have a much cleaner revision history than mercurial:
... and since there are a lot more developers than release managers, well, you better deal with it, as the likely response to any whining will be:
Someone pointed out that bisection works a lot better if the revision history is clean, if only because it's more likely that all revisions compile right.
ReplyDelete