I literally forgot about Mercurial. It’s been years since I’ve even heard it mentioned. Are there any strong arguments for using it over Git these days? Is this just about supporting legacy code bases. I’m sure there must be a way to migrate to Git [and maintain history]. I’m not trolling, I would love to hear from someone who prefers Mercurial over Git as to how it benefits them.
Sourcehut welcomes Bitbucket refugees
161–170 of 219 posts
Re: Sourcehut welcomes Bitbucket refugees
#162Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?
We're currently migrating all of our mercurial repos to git. The migration is trivial and retains the full history.
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.
Re: Sourcehut welcomes Bitbucket refugees
#163I literally forgot about Mercurial. It’s been years since I’ve even heard it mentioned. Are there any strong arguments for using it over Git these days? Is this just about supporting legacy code bases. I’m sure there must be a way to migrate to Git [and maintain history]. I’m not trolling, I would love to hear from someone who prefers Mercurial over Git as to how it benefits them.
Our company use mercurial and we are very happy with it. Mercurial has evolved and it's UI is still better than git. We use it due to following reasons:
1. Very easy to use and very well documented with a book.[1]
2. Mercurial good python philosophy of "explicit is better than implicit". This means every merge also needs to explicitly committed preserving history. Our team likes it.
3. Better multi-platform support.
4. Easy to extend to fit specific workflow.
5. Just run hg serve and access a beautiful web interface to review code. No need of external tools. In this aspect though fossil-scm [2] is ahead of both git and mercurial.
Re: Sourcehut welcomes Bitbucket refugees
#164I literally forgot about Mercurial. It’s been years since I’ve even heard it mentioned. Are there any strong arguments for using it over Git these days? Is this just about supporting legacy code bases. I’m sure there must be a way to migrate to Git [and maintain history]. I’m not trolling, I would love to hear from someone who prefers Mercurial over Git as to how it benefits them.
In my limited experience with Hg, I thought it had a well designed, human-friendly interface. After a decade with git, I still feel like it's an ugly, awkward tool that just gets the job done and I still occasionally make weird mistakes with it. I'm not sure that's the case with other tools I've been using this long.
Git has a pretty gross interface, such that people have struggled to make it nicer to use with GUIs for as long as I can remember. I also feel as though every junior developer has panic inducing moments with git where they think they've lost work or something terrifying like that. It's like a hazing ritual in programming. Wait for git to give you a heart attack. If you survive, you're one of us.
Hg didn't really give me that impression at all and I was excited to begin using it more, but like with most technologies I want to adopt, work and family won and I stuck with git at work and otherwise had no time to use Hg more. It seems like git won largely because it has the right buy-in from the right people.
Re: Sourcehut welcomes Bitbucket refugees
#165Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?
There are a few good things about it compared to git (and a few bad ones). One I like is that it has an excellent GUI that is cross platform, called TortoiseHg. I know hackers can be a bit snobbish about GUIs but I really think a GUI is essential for version control: flicking through the revision graph in one pane while looking at the modified files in another and a file's changes in a third is much more efficient th…
> And picking source and destination commits for a rebase is much easier visually on the commit graph than making note of hashes on the command line.
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.
Re: Sourcehut welcomes Bitbucket refugees
#166Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?
Technically I think Mercurial would be better for engineering wise in the long term. 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 s…
> 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).
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.
Re: Sourcehut welcomes Bitbucket refugees
#167Earlier quoted context omitted.
AKA the commands actually make sense, and they have sane defaults so you don't have to remember 100+ random flags.
People always claim this in mercurial posts, but it's really hard to tell to what extent this is just that people who are using hg all the time are familiar with the hg commands and so don't notice the problems any more. 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…
I think it's also at least somewhat the case that hg had a great CLI when it launched and git had an abysmal CLI when it launched, but over the years and counting "necessary" hg extensions, they've both sort of converged more towards the middle: git's has only gotten better (and really only had room to get better) and hg's has mostly stayed the same, if not slowly gotten worse from the additional "overhead" of extensions.
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.)
Re: Sourcehut welcomes Bitbucket refugees
#168[deleted]
Re: Sourcehut welcomes Bitbucket refugees
#169I honestly would have been surprised if Sourcehut shunned Bitbucket refugees. Water is wet, news at 11?
Re: Sourcehut welcomes Bitbucket refugees
#170I tried sourcehut a while ago but I found the pull request flow to be confusing. There aren’t actual pull requests but instead some sort of email flow that I didn’t have time to figure out. If there was a video walkthrough for the process, it would help people like me get the ball rolling faster
There's no video (that I know of) but Sourcehut has put up a website with a set of steps/instructions for email based pull requests: