Serious questions...
What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?
What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?
Mercurial has a single implementation (Git has 5), and they greatly discourage anyone from implementing a second. This gives them a single source of truth for the implementation.
Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change).
It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).
The file system changes were extremely low level and likely couldn't have been handled with extension hooks in Hg either (some of it, from what I read of it, would be more like the equivalent of changing the Python standard library, specifically the OS and file-system-specific bits, underneath Hg than changes to Hg or its extensions). It was also a relatively short-lived fork as it did merge upstream.
> It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).
Since Microsoft has taken an active role in git development, and especially since the Windows team itself switched to git, the official Git for Windows install and support for that install has been really good. While git will likely always need some bits of Linux abstraction because how much of it's "high level" is written in Bash shell scripts and random bits of awk / sed / perl, it certainly seems that the low level stuff is less reliant on Linux abstraction than ever and is increasingly cross-platform-intended C. (Just about every major performance boost across the board has usually included rewriting to directly cross-platform code.)
Python will always generally be "simpler/stabler cross-platform" for Mercurial, but git has done a remarkable job at catching up on the cross-platform space over the years.
We use the hell out of this at my company. Mercurial's hooks have made a wide variety of automatic tasks much easier to systematize across all our repos for any repo-related action that any dev makes.
Here's one of our use cases. Mercurial, at least in the early days, had much better support (IMHO) for large/binary files than git (perhaps git is on-par now, not sure). We needed some of the projects in our repos to be fully compilable against any binaries/assets at any point in time in the repo's complete history. We implemented this with a combination of Mercurial's first-party "largefiles" extension, high compression of our binaries/assets (via 7z), and a variety of scripts/hooks to (de)compress the relevant files whenever `hg commit`, `hg up`, `hg revert`, etc. is performed.
Sure, you greatly increase the size of a repo on whatever machines are serving it, but storage is cheap these days so who cares. Devs also have to deal with more disk space being used, but a) storage is cheap and b) it is trivial to clear old binaries/assets from their disk on an automated schedule. Whenever they update/revert to another revision/branch the binaries/assets download automatically anyway.
I don't see why. I've seen companies switch from Mercurial to Git even though many employees loved Mercurial -- the driver was the fact the new employees were much more likely to prefer Git or not even know what Mercurial is. Mindshare matters.
> Mercurial has a single implementation (Git has 5),
Eh? I very much like that there are multiple Git implementations. Besides choice, this means there are more people who really understand its guts and can support it and its implementations.
> and they greatly discourage anyone from implementing a second.
That's not a good thing.
> This gives them a single source of truth for the implementation.
That gives them too much power to make changes the users might not like.
> Mercurial has better hooks in place.
Sounds like one of the ways in which Git implementations might differentiate from each other.
> It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).
MSFT is doing amazing work on Git on Windows, making it scale in ways no other distributed VCS is likely to any time soon without adopting similar ideas. If you want Windows support, then Git is going to rock your boat more than Mercurial soon if not already.
Related question: does anyone know of a good git GUI that works on Windows and Linux? (Ideally, but not essentially, free.) I tried GitKraken and it failed at the first thing I tried to do with it (I wanted to stage a file I had just created, but it didn't have a way to display untracked files).
From my experimenting, I'm liking Sublime Merge as my favourite git GUI so far. It's nagware (i. e. no time limit evaluation period) like sublime text, and costs US$99 to remove the nag and enable the dark theme. It is pretty and functional without being overwhelming in its interface.
[alias]
l = log --date-order --date=iso --graph --full-history --all --pretty=format:'%x08%x09%C(red)%h %C(cyan)%ad%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08 %C(bold blue)%aN%C(reset)%C(bold yellow)%d %C(reset)%s'
If you don't want to learn rebasing and other Git fun, I'm not sure how much this will help you, but for me it's invaluable when it comes to identifying the base of my branch and where I would like to transplant it to.
Along with the basic "git pull --rebase" I also frequently use "git rebase --onto" and "git pull --rebase=merges" or "git rebase --rebase-merges" in my projects in order to manage branches that were created in an order other than what I want them to merge in. This keeps the history nice and linear, so I can avoid having any commits with two or more parent commits.
I don't find there's much else I would want to have a GUI to help with. But without a git graph that I can scroll freely, I feel as if I could not do my day-to-day work with such ease. This makes the most usable git graph with colorized edges and may be all you need. That, along with a nice PS1 setting so you get some branch status information right in your terminal status line without asking for it every time.
[alias]
glog = log --date-order --graph --all --date=short --pretty=format:"%x09%C(auto)%h %C(cyan)%ad %C(green)%<(12,trunc)%aN %C(reset)%<(50,trunc)%s %C(auto)%d"Heard of Fork [1] and switched in a heart beat. Works like a charm and looks great. Unfortunately only for Windows and Mac. I fall back to the command line on Linux.
[1] https://git-scm.com/docs/git-gui [2] https://git-scm.com/docs/gitk
In git branches are more comparable to hg bookmarks and used so heavily it feels very rare from the command line where you would directly use a hash rather than a branch name.
> Related question: does anyone know of a good git GUI that works on Windows and Linux? (Ideally, but not essentially, free.)
If you are happy with the Tortoise family there is a TortoiseGit [1]. I think the Tortoise "family" still shows its roots in SVN much too often to be a "great" Git GUI, but it should certain feel comfortably familiar. Though like TortoiseSVN, TortoiseGit only supports Windows. It's interesting that TortoiseHg was the only one in the "family" to invest in cross-platform.
GitHub Desktop can be a useful cross-platform GUI sometimes, especially for somewhat less code-focused folks. While it puts GitHub front and center, it's still a general purpose enough tool.
Git has an "okay-ish" cross-platform GUI that is almost always bundled with it called "Git GUI". I don't know a lot of people that recommend the main interface for Git GUI, it's an ugly Tk-based throwback, but it does cover almost all of the basics of TortoiseGit without as much direct shell integration. (It has some bare shell integration into the right-click context menu as an optional checkbox buried in the Windows install at least.) On the other hand, while almost no one uses the main commit-oriented parts of Git GUI, its commit graph viewer `gitk` (which is almost always available in the PATH by that name) is almost an almost indispensable power tool, and I think still the commit graph tool to beat for git. `gitk` is great, and years ago became my muscle memory over `git log` for a lot of situations.
At this point the most common cross-platform "GUI" I use day-to-day with git though is just VS Code. It's built in git support is sufficient for a lot of work, and there are some useful, optional power tool extensions like "Git Lens" that make it even better.
There are extensions that cover more advanced cases, too, such as creating/reviewing Github PRs, reviewing the commit graph, etc.
Now, I last used git extensively in 2011, and I have heard things have gotten better on the UX front. But now I am used to HG and don't have many reasons to switch. I gladly pay 20 bucks a year for having a place for mercurial repos.
With mercurial and darcs I never had that happen. Losing code is a deadly sin for a SCM should be behind at least 2 confirmation dialogues.
Whenever pijul reaches 1.0 I will probably switch to that. It seems like patch theory done right.
After working with mercurial for the last four years, I don't think it offers anything that git doesn't. I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics). Integration with third-party tools and services is nonexistent. The move to git is allowing us to leverage a world of tools, as well as allowing us to skip bringing every new developer up to speed with mercurial.
Not true.
Out of the box with no extensions required, Mercurial supports bookmarks, which are functionally the same as Git's branches. Also, Mercurial supports even lighter branching compared to Git using anonymous branches.
This blog post from 2009 explains it all: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
Mostly true. I've read the post you linked to; all of those approaches have significant disadvantages compared to standard git branches. We used the bookmark-based workflow for a while, and it's simply not as good as a git branch. The evolve extension and topics were build for this reason, and they finally approach a decent workflow that allows for things like cleanly discarding experimental "branches" that have been pushed to a remote.
As a irregular hg user, I frequently run into (or help others with) issues with the ui, like "why does `hg log require `-f` to do something useful", "how do I refer to the current head commit (protip: it's not `tip`)", "how do I see changes relative to a branch (bookmark) on a remote" and "which set of commands am I supposed to use for history rewriting nowadays and how do they work?".
hg has some nice features, but the idea that it's got a fully intuitive and uniformly well designed interface is, in my experience, a total myth. Which isn't to say that git has a great CLI of course, just that the extent to which hg is better in this area is often overstated.
Which is that the difference between the CLIs in the early days were stark contrasts of good and bad, but now they both seem about equally mediocre, but in different ways, when directly contrasted. (Especially with the latest git release finally splitting checkout into switch and restore, they are really on increasingly similar footing.)
Not true. In fact, Mercurial is faster than Git on huge repositories; just ask Facebook--the entire Facebook application lives in a Mercurial mono repository, which wasn't possible without Git slowing to a crawl: https://engineering.fb.com/core-data/scaling-mercurial-at-fa...
Turns out it's been easier for Facebook and others to optimize Mercurial over the years due to it being 95% Python, which is easier to refactor.
And because of Mercurial's extensibility, it's easier to replace or optimize different components.
Granted, this was a personal project and I didn't use much branching, but I remember the transition and history were pretty seamless.
I originally started with Bitbucket, and then transitioned to a small hosting service after Bitbucket had extended downtime. (I just had to update my Mecurial repository to push to a new host.) Then, the transition to github was almost as easy.
(If only I could remember the tool I used. Maybe my private Mecurial host allowed pulling with git? I just don't remember!)