Hg Init: A Mercurial Tutorial
hginit.github.io
hginit.github.io
Mercurial otoh was a joy to use, never surprised me - it just worked. I think github is the only reason git won. Ah well, water under the bridge...
P.S.: hginit rules.
It's very annoying that git became more popular, it's such a disaster from the usability point of view.
Can you provide a single example of what you think is the absolute worst userflow that git provides for a basic everyday feature? I'd like to understand why some people repeatedly make a mountain out of a molehill regarding git's user experience.
https://stackoverflow.com/questions/tagged/git?tab=Votes
This is not the mark of good interface design. The ones I look up every single time off the top of my head are:
# undo commit
git reset --soft HEAD~1
# unstage
# was git reset HEAD --
git restore --staged
# https://stackoverflow.com/questions/2003505
nuke = "!f() { git branch -D $1 && git push --delete origin $1; };f"
A few times I tried the rebase workflow geeks are always pushing. They are never around when disaster strikes, so I don't bother any more. At least merge+squash works every time.
Notice that commands like git status tell you what commands to run to fix issues; the typical user would never guess. Hg wasn't perfect but it had a lot fewer of these issues.
I don't understand this sort of comment at all. What's so hard about git?
You clone a repository, you checkout a branch, you pull changes to that branch from the remote server, you commit a change to your local repository, you push those changes to a remote server.
What's so hard to get?
It's even more absurd when people try to claim that mercurial is so clear while criticising git for being unintelligible, when mercurial follows the exact same patterns but had to confuse people by leaving basic features like stashing as an afterthought to be implemented with ad-hoc extensions.
> Although Mercurial was not selected to manage the Linux kernel sources, it has been adopted by several organizations, including Facebook, the W3C, and Mozilla. Facebook is using the Rust programming language to write Mononoke, a Mercurial server specifically designed to support large multi-project repositories.
Mercurial @ Google:
> Speaking of Google, their Mercurial rollout on the massive Google monorepo continues. Apparently their users are very pleased with Mercurial - so much so that they initially thought their user sentiment numbers were wrong because they were so high! Google's contribution approach with Mercurial is to upstream as many of their modifications and custom extensions as possible: they seem to want to run a vanilla Mercurial out-of-the-box as possible. Their feature contributions so far have been very well received upstream and they've been contributing a number of performance improvements as well. Their contributions should translate to a better Mercurial experience for all.
https://groups.google.com/g/mozilla.dev.version-control/c/hh...
The import of something that large unfortunately took a few hours, and it's a bit annoying that under the hood hg-git needs to store both the native Git repository as well as a copy converted to a Mercurial repository, but other than that it works quite fine in day-to-day usage.
And with smaller repo than something like Firefox's the above disadvantages are of course less to hardly noticeable.
Is there a reflog, though? When I mess up a git rebase, I have confidence I can always undo the rebase and try again.
When I used Mercurial, admittedly over five years ago, there wasn't a reflog. Sure, you'd get some .bak files when editing the history, but that's nowhere near as safe.
Have a branch-a that depends on branch-b that depends on branch-c that upstream just rebased and squashed some of its commits? More often than not `hg pull && hg evolve` is all you need to do to synchronise everything. This makes stacked PRs much easier to manage.
I get everything Joel says in that first page svn rant, but, part of me was like "well why did you choose to use it that way then?".
Even the whole "hg/git are decentralised, svn is not" mantra bothers me. So friggin create a personal svn repo and merge back when ready already. I've used a decentralised svn workflow more times than I can count now. It's really not that hard.
The point is that it took work for you to set that up with SVN, which most people don't do. Git gives it to you for free.
Also, autocomplete is still an additional keypress...
Agreed, but at least for git, this is easily resolved:
# $HOME/.gitconfig
[alias]
br = branch
co = checkout
st = status alias gs='git status'
alias gco='git checkout'
alias gb='git branch'
alias gp='git push'
alias gf='git pull' # aka fetch
# and many more
Perhaps:
* https://www.mercurial-scm.org/wiki/GitConcepts#Git.27s_stagi...
- It limits the amount of time changes are stored in an intermediate state, making it much less likely to interfere with other operations, like pulling and switching branches.
- You can use the same commands (and mental model) to manage the "staging area" and other commits.
- The history of staging and unstaging becomes actual history and can be recovered and shared.
Further slowed by HHVM deciding to crash itself after a "large" rebase to download type checker saved state remotely because that'll somehow be faster than rebuilding it locally is...
At one stage he was giving out free paper copies that I have on my shelf somewhere...
Back in the day we used SourceGear for our source control which worked well enough for our needs. Oh the days of exclusive file checkouts :)
After switching to git, it felt complete. Yes, git UI is horrible and has the drawbacks of the snapshot model. But it is perfect for a team setting. This is why GitHub won and in turn git.
I suppose its is a less dated version of Vi vs emacs, I just found Mercurial to be easier to use.
But hey, at least those workflows are probably ISO 9001 certified! /s
I.e. cases where you typically exchange documents over email/dropbox and use extension-based versioning (e.g. report.v22.final.docx). Subversion keeps all data in one repository nice and tidy. Works well with binary files. Allows easy subtree checkouts. Plus, explicit commits make it easier to track progress without having to dig in your mailbox.
Makes sense, as SVN is basically a centralized versioned file system.
Granted their business was manufacturing electronics for passenger aircraft, so any change in their tooling might trigger an expensive, multi-year recertification across their product line, so maybe they were right...
Git: 50 mins of googling to know what the next 5 commands to type. Hg: 5 mins of googling to know what the next 50 commands to type.
That's quite the odd statement, as all it takes is a 5min tutorial to get up and running on 95% you ever need to do with git on a weekly basis, and 100% of what you do at an everyday basis.
> Hg: 5 mins of googling to know what the next 50 commands to type.
This is not the brag you think it is. If you need to know 50 commands to do daily work with a revision control service, that service is appallingly broken by design.
Also, you forgot to mention the need to install ad-hoc extensions in mercurial to have access to basic stuff.
It's odd only if you are new to DVCS. In the early days of git and hg, git commands were lots of plumbing and very little porcelain. At the time, most people switching from svn to a DVCS almost universally found hg a basically effortless switch. The success of git is due to 1) Linus fandom/cargo cult. 2) Ruby on Rails groupthink, and 3) Github.
> If you need to know 50 commands to do daily work with a revision control service, that service is appallingly broken by design.
Commands to type.
Consider just the simple task of "forget about the last commit I made." Mercurial has like five different ways to do this (hg rollback, hg uncommit, hg strip, hg prune, hg histedit), which work in three totally different ways under the hood (obsolescence markers, backup bundles, or just YOLOing it in the case of Rollback), and which may change their behavior depending on whether you're using `evolve`. As a novice, it's not clear which you should be using (hint: use the evolve extension) or how to recover from mistakes.
Git also has several ways to do it, but all operating on the same principles. Whether you `git reset` or `git branch -m`, or `echo $(git rev-parse $BRANCH~) > .git/refs/heads/$BRANCH`, you're just moving pointers around, and the reflog makes recovery simple.
Wow 5 commands, none of which have a confusing - or -- flag, or are an overload of another command? That's really impressive.
I've been using git non-stop for 7 years at this point. I have no idea how to "forget about the last commit I made." off the top of my head. I'm sure one day soon I'll need to do it, will look it up, and then forget it immediately because gits cli makes no sense.
git config --global alias.uncommit 'reset --soft HEAD^'
Just click the Undo-Button: https://tortoisehg.readthedocs.io/en/latest/_images/commit.p...
And in the last 3 years I used Git a lot more than Mercurial.
But even using Mercurial day-to-day, I had to look up whether `hg strip` or `hg uncommit` has `evolve` integration (no and yes, respectively), and I'm not sure I could fix botched history edits.