Hg Init: A Mercurial Tutorial(hginit.github.io)
hginit.github.io
Hg Init: A Mercurial Tutorial
https://hginit.github.io/
88 comments
Sourcehut (sr.ht) has Mercurial support in their forge (in addition to Git). Was one of the main reasons for me moving projects over there in the first place, but I really enjoy the simplicity of the UI and general minimalist approach. I don't know whether it does CI/CD pipelines or anything, since I've little call for any of that, so ymmv.
It does do CI/CD, for what it’s worth[1,2]
[1] https://builds.sr.ht/~sircmpwn/builds.sr.ht
[2] https://man.sr.ht/builds.sr.ht/
[1] https://builds.sr.ht/~sircmpwn/builds.sr.ht
[2] https://man.sr.ht/builds.sr.ht/
Agreed, mercurial is a joy to use.
It's very annoying that git became more popular, it's such a disaster from the usability point of view.
It's very annoying that git became more popular, it's such a disaster from the usability point of view.
> It's very annoying that git became more popular, it's such a disaster from the usability point of view.
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.
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.
Because of the other 8 million things you can do with git, especially when things go wrong and you're trying to undo them and the commands are very cryptic.
Have zero problems with it, have you tried to RTFM?
Yes, I read the manual every time I need to do anything but push and pull. Because I have to. ;-)
> Yes, I read the manual every time I need to do anything but push and pull. Because I have to. ;-)
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.
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.
It's no molehill, and they are well known. Just go to stack overflow and see git questions with ~20,000 votes each! Not just that but note how many answers there are for each one, how much story-telling is involved, and how advice changed over the years:
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:
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.
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 still save changes to a file if I switch/merge while having a bigger changeset as I use PHPStorm and it caused me a semi heart attack at least 3 times with the “unstashing failed“ error (that also removed it from the stash at the same time)
The best thing about Jetbrains IDEs is local file history - so you dont have to rely on git - you can still see file history and directory history to restore commits and deleted files. Saved me many times.
VS Code added that feature too recently, very nice addition https://code.visualstudio.com/updates/v1_44#_timeline-view
Thanks I didn't even know that was there, this will help me. It looks like its files only, not directories which is important to get accidentally deleted files.
Local history is great and I dont understand why it's separate from the undo stack, which is limited in size (by default?). Actually, both could be integrated with SCM as fine grained autocommits + eventual squash on manual checkpoint / push.
The other option here is to do a "WIP" (work in progress) commit. Which you can undo (moving the files back into the staging area) with `git reset HEAD^` once you switch back to the branch. Annoying that this is necessary - it would be great if git stash was as robust - but this won't lose your work.
You can also use `git stash apply` (which doesn't pop the stash), followed by maybe merging, and finally a `git stash drop`.
You can also use the git reflog to get the recently dropped stash commit's sha, and then check out the files that you miss.
If a change has ever been committed or stashed (which is basically also committing, just not on a branch), it can always be recovered, at least until garbage collection is run - check out the reflog. Of course, if it hasn't been, then you can lose it.
Yeah, working out which stash contains your work can be quite tricky though! As they are not named by default.
You can add a tag to the change you want to keep. Whatever you do, you can recover it (git reset --hard tag). Once you are done, remove the tag. Otherwise, there is the reflog, like mentioned in a sister comment.
standard branches can serve this purpose
Mercurial @ Facebook & Mozilla, per Wikipedia:
> 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...
> 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...
I always wanted Mercurial to "win" and be the next hotness. I preferred it to git. But, I was assimilated and haven't looked at it in some time now.
When I first got into distributed source control I found Mercurial much easier to use. Even though Git has "won," threads like this are a good reminder that there are git bridges for Mercurial that allow you to run Hg locally and then push/pull/branch/etc with a Git remote repo. I need to look into that again.
I've successfully used hg-git on something as large as Waterfox (slight irony there because Waterfox is a Firefox fork, and Firefox's canonical repository is a Mercurial repository, though they also maintain a Git mirror).
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.
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.
I'm using hg-git... was fine until i started working with other humans. my changeset hashes don't match github and git branches map to hg bookmarks which i don't like.
Maybe some day we will have https://gitinit.hghub.io/
The way some histories tell it, Git didn't win because it was better than Mercurial but because GitHub arrived on the scene and exploded in popularity. Had GitHub been HgHub it's possible that we would be programming in a Mercurial dominated world with Git having been "the other" that fell by the wayside.
Having used Mercurial at the time, I can strongly vouch for GitHub being a massive draw toward using git. I 100% believe this narrative.
Last time I had to use Hg on a client project, disposable topic branches didn't seem to be something really supported. Broke our usual workflow and made a small mess for the client. Is this still the case?
Git-style branches are called bookmarks[1] in Mercurial and "rebase -i" is called histedit[2]. It works pretty much the same.
[1] https://www.mercurial-scm.org/wiki/Bookmarks
[2] https://www.mercurial-scm.org/wiki/HisteditExtension
[1] https://www.mercurial-scm.org/wiki/Bookmarks
[2] https://www.mercurial-scm.org/wiki/HisteditExtension
> "rebase -i" is called histedit. It works pretty much the same.
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.
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.
No reflog, but there is the obslog, which stores obsolescence history of individual revisions. Better yet, the obslog is distributed during pull / push. Because Mercurial knows precisely which commit is replaced by which commit, it can automatically resolve a lot of conflicts that result from history editing.
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.
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.
Unless you explicitly set config otherwise, any time you rebase / strip / histedit, a copy of the original commit(s) gets saved and can be restored with a single command.
supposed to use bookmarks in hg but i used named branches anyway and that worked perfectly fine too
Am I alone in liking svn? Like, not necessarily "more" than hg/git but not "less" either.
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.
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.
> 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.
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.
Absolutely. Just at a different cost.
It is true that svn has improved over the years since dvcs became mainstream. New workflows developed as well. Unfortunately no one wants to use anything but git+hub any longer. Networks effects sucked all the air out of the room. gitlab is decent I have to say however.
One thing I miss about Mercurial was only having to type enough of a subcommand to be unambiguous. `hg st` is much shorter than `git status`. I wish all CLI tools worked that way.
> I wish all CLI tools worked that way.
Agreed, but at least for git, this is easily resolved:
Agreed, but at least for git, this is easily resolved:
# $HOME/.gitconfig
[alias]
br = branch
co = checkout
st = statusNeat, but long ago even that became too much. I use a bunch of alias like this:
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
How does that differ from tab autocomplete?
It's built in to the Mercurial CLI, whereas tab autocomplete is an additional feature to the user's shell. Thus, by default, every user will have access to the Mercurial shortnames, while only users with autocomplete enabled in their shell (or with autocomplete available for their shell) will have the autocomplete available.
Also, autocomplete is still an additional keypress...
Also, autocomplete is still an additional keypress...
I used hg for years at BigCo, and it’s good, but damn did I miss the git index. Which is kind of amusing given that the git index took a bit of getting used to.
You can use `hg commit --interactive` to use the the commit itself as the staging area. And I'd argue that's a better model because:
- 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.
- 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.
> […] did I miss the git index.
Perhaps:
* https://www.mercurial-scm.org/wiki/GitConcepts#Git.27s_stagi...
Perhaps:
* https://www.mercurial-scm.org/wiki/GitConcepts#Git.27s_stagi...
The index is an anti-feature in my opinion. People commit in chunks with no guarantees that these commits that are valid all together are valid individually.
Mercurial at FB gives me rage attacks. It's soooooo fucking slow. Not sure if it's Mercurial itself, or the FB codebase though.
The transition to Eden has been... weird. Like, I'm sure it's actually meaningfully better in certain metrics but yeah the fact that rebasing from one local commit to another local commit requires a bunch of network I/O is non-obvious and slow... Checkouts feel so much slower, too.
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...
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...
There is also this online book by Eric Sink: https://ericsink.com/vcbe/index.html
At one stage he was giving out free paper copies that I have on my shelf somewhere...
At one stage he was giving out free paper copies that I have on my shelf somewhere...
I managed to get a free paper copy as well. It lives in my bathroom library and gets opened now and again.
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 :)
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 :)
I was a very long time user of mercurial since it's early inceptions. It helped me really visualize the work as a set of patches. It has history rewrite feature on local, but it doesn't allow to force push the rewritten history/branch. We had to do lots of work arounds, processes, etc to cover for the lack of.
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.
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.
Does anybody else remember Bazaar? bzr was the first DVC I used, right before switching to hg. I liked hg more than git and still use it on one project but git just took over. I think git's adoption was not only pushed by GitHub but also by being faster. HgHub would probably still not have won against GitHub due to its early popularity in the Ruby on Rails community and since self-hosting Mercurial over https was much easier compared to git.
I remember using an experimental feature of bzr to branch from subversion (that my employer then used), make local commits using bzr and merge back to svn. That was so cool.
Yes! That was actually one of the reasons why we used it, too. Ist looks like Breezy, the friendly successor/fork still supports this.
What a pleasure was to use Mercurial.'
So happy to see this back. This used to live on hginit.com. After it disappeared I had refer friends to the archived site via archive.org.
I suppose its is a less dated version of Vi vs emacs, I just found Mercurial to be easier to use.
I suppose its is a less dated version of Vi vs emacs, I just found Mercurial to be easier to use.
Page mentions Subversion, anyone still using that vcs these days?
Subversion is still my favourite VCS for collaborating on non-source data.
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.
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.
> Subversion is still my favourite VCS for collaborating on non-source data.
Makes sense, as SVN is basically a centralized versioned file system.
Makes sense, as SVN is basically a centralized versioned file system.
Hell, I had one client still using CVS a few years ago, and they couldn't see any reason why I was suggesting they might want to change.
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...
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...
The OpenBSD project still uses CVS.
A LOT of companies still do. Every bigger company i've been to here in germany has used it somewhere. Some tried to slowly move to git, most didn't, because svn just works and old people don't want to change
I would not be surprised if there were source control management workflows involving faxing things somewhere here in Germany... sigh.
But hey, at least those workflows are probably ISO 9001 certified! /s
But hey, at least those workflows are probably ISO 9001 certified! /s
I'm sure plenty teams at engineering companies do. These people mostly are not SW developers by training (i.e. they write SW incidentally), and SVN is an order of magnitude easier to use than git.
I agree and yet git has pushed itself almost everywhere.
WordPress plugin deployment depends upon on Subversion
oh yes...
Mercurial just has better UX so less need to Google
Can confirm.
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.
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.
> Git: 50 mins of googling to know what the next 5 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.
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.
> That's quite the odd statement
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.
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.
That was not my experience at all.
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.
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.
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),
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.
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.
I can’t remember git commands either. I simply add them to my git config. So I type “git uncommit” and get the behaviour I need. For example:
git config --global alias.uncommit 'reset --soft HEAD^'
git config --global alias.uncommit 'reset --soft HEAD^'
The best UX has TortoiseHg
Just click the Undo-Button: https://tortoisehg.readthedocs.io/en/latest/_images/commit.p...
Just click the Undo-Button: https://tortoisehg.readthedocs.io/en/latest/_images/commit.p...
Just from a quick read of the docs, isn't 'undo' just 'rollback' (dangerous, deprecated)? Can you undo an undo?
The amusing thing about your comment? I could immediately think of at least one way to do it in Mercurial, whereas with git I didn't - I would have to Google it.
And in the last 3 years I used Git a lot more than Mercurial.
And in the last 3 years I used Git a lot more than Mercurial.
Again, I've had the opposite experience. I've used nothing but Mercurial at work for the last 2.5 years, and yet how to do this in git was obvious (and `git rebase -i HEAD~` gives a fourth way).
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.
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.
[deleted]
Off topic, but the drop-off in searches during pandemic seems to indicate how little work people actually did whilst working from home...it's quite surprising.
Yes, git is more popular than hg. Keen observation, there. /s
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.