Mercurial and Git
Thursday, September 15, 2016, 12:38 PM
These are the most prominent writings, along with testing each tool with the kinds of code I write, that led me decide that for my purposes I'd settle on Hg instead of Git to be the default.
Mercurial is generally believed to be simpler and easier to learn than Git. In turn, there is often the perception that Git is more flexible and powerful. This is due, in part, because Git tends to provide more low-level commands, but also in part because the default Mercurial tends to hide advanced features, leaving it to users to edit the mercurial config file to activate the advanced features they like..
From <http://www.wikivs.com/wiki/Git_vs_Mercurial>
I prefer ease of use. I don't mind sacrificing some advanced features for that as I'm only a part time developer. (There are many persuasive articles that "more advanced" Git meme is perception more than reality.)
I think there’s still one very, very important difference left: the systems feel very different to use. […] How a system “feels” matters. Version control is something you use constantly, so it’s important to find a system that fits your way of thinking. […] visualize the difference between Mercurial and git -→
Each git command is like a Swiss Army knife. For example, git checkout can switch the working directory to a new branch, update file contents to that of a previous revision, and even create a new branch. It’s an efficient way to work once you learn all the arguments and how they interact with each other.
Mercurial is like a well-equipped kitchen — it has a lot of tools that each do one simple, well-defined thing, … there are more commands to learn, but each command is much simpler and more specific to a single conceptual task. […] I personally find Mercurial’s philosophy easier to work with.
From <http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/>
…Quite simply, Mercurial is better at merging than Git.
[…] the literature for Git and Mercurial use the word branch to mean crucially different things […] For the concept described in the Git literature with the word branch and in the Mercurial literature with the word head, I shall use the word lineage. I shall use the word family when referring to the concept the Mercurial literature uses branch to describe, which is a name that distinguishes a related set of lineages.
Mercurial is superior to Git because it records family history in the repository, while Git does not. In every other significant respect, a Git repository stores the same information as a Mercurial repository. This is why it is possible to convert a Git repository into a Mercurial repository then back into a Git repository without losing any information. It is not possible to perform this round-trip starting with a Mercurial repository (in the general case) because the family history must be discarded in the conversion to Git. (In the conversion to Mercurial, the entire Git repository can be regarded as one monolithic family, and indeed this is how the excellent Hg-Git tool presents its Mercurial view of Git repositories.)
It turns out that having the family history recorded in the repository— and thereby copied around with clones, pushes and pulls— is really important when reviewing the history of a project.
From <https://jhw.dreamwidth.org/1868.html>
…I'm interested to know what differs hg and git without having to jump into a fanboy discussion.
Git vs. Mercurial: Please Relax (Git is MacGyver and Mercurial is James Bond)
From <http://stackoverflow.com/questions/35837/what-is-the-difference-between-mercurial-and-git>
This one's hard. My temperament is definitely MacGyver, not a cool or suave bone to be had in my body. ;-)
Assorted mish mash of emotional "just because" reasons I chose Hg:
Both Facebook and Google and use Mercurial for their master repositories
Facebook is 62 million lines of code and git has became slow for the engineers at Facebook. So, they decided to make mercurial faster than git.
From <http://blog.prasoonshukla.com/mercurial-vs-git-scaling>
Google Is 2 Billion Lines of Code—And It’s All in One Place - […] It’s based on an existing system called Mercurial. “We’re attempting to see if we can scale Mercurial to the size of the Google repository,”
From <https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/>
Mercurial is written in Python. I like python.
Joel on Software likes Hg. I like Joel's writing; he makes me think more deeply and is persuasive:
Hg Init: a Mercurial tutorial - In this user-friendly, six-part tutorial, Joel Spolsky teaches you the key concepts.
From <http://hginit.com/>
─────────────────────────────────────────────────────────────────────────────────────────
Oliver says:
@muxator: the repository has the progress since the 2007 release, but nothing stable has transpired. I have just resumed working on WDS and the stuff surrounding the TODO list after several months of “hiatus” (new work place, daughter in kindergarten age etc) and hope to publish another pre-release version before the end of this year (one code-signed version can be downloaded in the download area on Bitbucket, including 64-bit binary).
@all: In general the aversion to Git is based on having used it for a very long time. I started using Git not long after I started with Hg (around 2008). In fact on a regular basis — at work — folks will approach me for advice regarding whatever kerfuffle Git has gotten them into again (because as much as those GUI tools attempt to hide, sooner or later you end up with gitglossary). SCM/VCS is supposed to help me do my job and save me time as a developer. Git — on a regular basis — does the exact opposite. Git will happily scream “here here”, asking my attention for stuff that I expect a supporting technology to solve for me.
While — with a very limited workflow — Git can be okay to work with, I never quite fancied that on Windows it would open a browser when I simply ask for --help. I also don’t quite like how questionable design decisions have led to wacky behavior (ever tried working on a repository with ref whose names differ only in case on Windows? … oh, but that only happens once the refs get unpacked … don’t even get me started on the innards of .git, because as a user you’re pretty much expected in several scenarios to know your way around there; or differently phrased: the internals of Git are part of its public interface …).
It’s true that CVS can’t be fixed, as Linus Torvalds so candidly stated in one of his first talks about Git, making fun of Subversion trying to do that so hard. Subversion made its own questionable decisions (you only learn to appreciate tags and branches as “paths” following a “convention” once a coworker “blesses” the repository with branching from the repository root), I guess many SCM systems did (including Hg). But given Hg and Git came along within months of each other and for the same reason (Linux kernel, getting away from BitKeeper) one has to wonder why Hg always had an overbearing design and never considered non-unixoid systems second-class “citizens”. With Git, on the other hand, commands kept sprouting and command line switches blossomed and .git internals (not just plumbing commands!) became part of its public interface … which makes me wonder if fundamental issues (many of which its developers will not even acknowledge as problematic!) with Git can ever get fixed.
GitHub, in my opinion, is the single biggest reason for Git’s “success” and I wonder almost on a weekly basis — basically whenever Git sticks me the finger again — why we developers put up with mediocre tools. And whenever people tell me they work with Git it oftentimes turns out what they mean to say is that they use GitHub and are excited by its client or they are excited by SourceTree or some other fancy GUI tool or the by the libgit2 integration of their favorite editor/IDE. Or to sum it up: many people go on about Git’s potential benefits while reluctant to explore/apply even a sizable fraction of those perceived benefits and sticking to very very limited (and limiting) workflows and still struggle on occasion as you can find out yourself with a cursory web search …
One may attribute the fact that there are dozens of books about Git in English alone versus one (that I know of) about Hg as indicator of Git’s success … I have a slightly different interpretation of that fact, though.
A small selection of my reasons for disliking Git (I am still collecting for an article albeit not for this blog):
Git is the very antithesis of Alan Kay’s statement: Simple things should be simple, complex things should be possible.
On this StackOverflow answer there is an excellent comment that sums up Git quite nicely (quoting Ian, another commentator on said question):
Ian: “the same could be said about Git (apart from windows support)” — Ehh-heh, you’ve apparently missed the “It’s easy to use” part. ;-p Git is the gold standard example of a tool with a user interface designed for its own developers as the target audience. It’s like driving your car via CAN-bus adaptors and prototype test equipment loaned from the R&D lab. Extremely powerful, but requires you being in the car industry. – Sz. Jan 24 ’16 at 23:20
Comments on StackOverflow are volatile, but I got screenshots showing question and comments.Overall usability and UX of the CLI … need I say more?
The Git index. Hardcore Git fans will probably get a seizure (oftentimes the index will come up in
discussionsflame wars about why Git is superior to any other SCM), but so what. Hg isn’t as powerful as Git out of the box (i.e. in its default configuration) because it doesn’t enable every shipped feature, such as those of the caliber allowing you to wipe out revision history. There are extensions for such features, which can be enabled on-demand. In Hg, if I really wanted to I could mimic it some way (MQ comes to mind), but in fact I’d like to keep a true history of the revisions, including small intermediate commits. If I wanted to, I could still squash the changes before pushing (i.e. before moving from draft to public stage).Stashing and unstashing and the issues it brings
Git still has second-grade support for Windows … regularly … mostly because Git expects to work in a unixy way on a non-unixoid system … However don’t take that the wrong way. Kudos to Johannes Schindelin and other developers for considerably improving over the experience of Git on Windows a few years ago … which was basically to install a MinGW-based toolchain, build it yourself and hopefully not forget to clean up the GiB of object files it left sitting around …
When I say branch my intention is that the next commit goes there … with Git you can do that (i.e. switch to the branch upon creation) with git checkout … wait, what? … and yeah git switch came along meanwhile to join the other two commands operating on branches … ugh
Git is lossy, … it may sound incredibly selfish, but I don’t want my SCM to be lossy (sorry)
Git can be horribly messy with line endings (and the tools it provides to mitigate these shortcomings are … suboptimal) …
git --everything-is-local is one of the PR claims on their website. Depends on how you look at it, I guess. Whenever I clone, I have to go through hoops to get everything from the remote end set up as a local verbatim copy. Sure, I can start out with git clone --mirror and “unbare” it, but setting up all the tracking branches from that to establish a real mirror is insanely hard (and involves shell script which makes those solutions less portable as well) … it’s the reason why Hg branches don’t map to Git branches in solutions trying to achieve interoperability. Git branches are mapped to Hg bookmarks in those cases (and bookmarks are exclusively local). So in the sense that “everything is local” until you decide to share it, that’s true. But it means that a clone does not in fact carry all revision history (which some people may like, but I decidedly don’t).
git clone via SSH isn’t two-way (I can clone from but not to a remote via SSH). The advice then is usually to pull from the remote one. Alas, that can occasionally be quite difficult. That is because, just being able to connect to a host via SSH, doesn’t — conversely — imply that this host can connect back to where I am connecting from. “Solutions” to this are regularly unnecessarily fiddly (and yeah, I am quite apt with SSH port forwarding and stuff) …
Syntax is regularly confusing … consider alone in how many ways you can express the exact same meaning for the URL of a remote.
The Git documentation is rather bad (several examples name arguments not mentioned in the syntax section etc.) and annoying to read from Git-specific terminology (man gitglossary again).
Git has an issue pushing to remotes with a checked out work tree. What the f…? As if pushing to a remote had to imply checking out those changes (it’s akin to fetch vs. pull … just in the other direction) …
The fact that the list of staged items does not indicate changed file modes is rather aggravating … this either means file modes should not be affected at all or if they are, the change should be explicitly visible.
All that said I am not planning on creating extra obstacles for contributors using Git. And I have researched several options that may provide a smoother experience for Git users. However, I am definitely not planning on transitioning to Git, but Heptapod, Kallithea, Phabricator and RhodeCode are being investigated as options.
As long as I am not paid to put up with Git (as I am at work), I’m not going to spoil my spare time with it 😁
…
From <https://blog.windirstat.net/20190821/project-repositories-will-move-to-self-hosted/#comments>