Hg Init: A Mercurial Tutorial

https://hginit.github.io/

by captn3m0 • 4 years ago

89 86 4 years ago

hginit.github.io

taspeotis• 4 years ago

https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...

moonchrome• 4 years ago

Mercurial just has better UX so less need to Google

wyuenho3• 4 years ago

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.

sio8ohPi3• 4 years ago

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.

faichai• 4 years ago

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.

gilrain• 4 years ago

Yes, git is more popular than hg. Keen observation, there. /s

benreesman• 4 years ago

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.

rubyist5eva2• 4 years ago

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.

throw0101a• 4 years ago

[…] did I miss the git index.

Perhaps:

* https://www.mercurial-scm.org/wiki/GitConcepts#Git.27s_stagi...

aayjaychan2• 4 years ago

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.

TheChaplain• 4 years ago

Page mentions Subversion, anyone still using that vcs these days?

albertopv• 4 years ago

oh yes...

s_dev• 4 years ago

WordPress plugin deployment depends upon on Subversion

dailykoder• 4 years ago

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

guitarbill2• 4 years ago

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

m000• 4 years ago

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.

arinlen4• 4 years ago

Subversion is still my favourite VCS for collaborating on non-source data.

Makes sense, as SVN is basically a centralized versioned file system.

mikro2nd2• 4 years ago

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...

SoftTalker• 4 years ago

The OpenBSD project still uses CVS.

BeetleB2• 4 years ago

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.

mixmastamyk5• 4 years ago

I agree and yet git has pushed itself almost everywhere.

xeyownt• 4 years ago

Maybe some day we will have https://gitinit.hghub.io/

mikece2• 4 years ago

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.

stouset• 4 years ago

Having used Mercurial at the time, I can strongly vouch for GitHub being a massive draw toward using git. I 100% believe this narrative.

bornfreddy• 4 years ago

I use git daily and it works, but man did it take a long time until I got confident enough to not make a backup.tar.gz before some more complex operation. And I still hate the fact that there are N additional obscure ways to do each operation.

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.

jefozabuss• 4 years ago

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)

Cederfjard• 4 years ago

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.

vbernat• 4 years ago

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.

rr8882• 4 years ago

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.

nicoburns2• 4 years ago

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.

mikro2nd2• 4 years ago

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.

mananaysiempre• 4 years ago

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/

jjav• 4 years ago

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.

waynesonfire• 4 years ago

Have zero problems with it, have you tried to RTFM?

arinlen4• 4 years ago

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.

gadders• 4 years ago

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...

teh_klev• 4 years ago

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 :)

georgia_peach• 4 years ago

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...

JustSomeNobody• 4 years ago

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.

systems_glitch• 4 years ago

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?

ptx• 4 years ago

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

orra• 4 years ago

"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.

8n4vidtmkvmk2• 4 years ago

supposed to use bookmarks in hg but i used named branches anyway and that worked perfectly fine too

srean• 4 years ago

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.

aaaaaaaaaaab• 4 years ago

Mercurial at FB gives me rage attacks. It's soooooo fucking slow. Not sure if it's Mercurial itself, or the FB codebase though.

Kilenaitor• 4 years ago

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...

kej• 4 years ago

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.

Panzer04• 4 years ago

How does that differ from tab autocomplete?

deadwanderer• 4 years ago

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...

quesera• 4 years ago

I wish all CLI tools worked that way.

Agreed, but at least for git, this is easily resolved:

  # $HOME/.gitconfig
  [alias]
    br = branch
    co = checkout
    st = status

mixmastamyk5• 4 years ago

Neat, 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

Interestingly, I ported these from hg aliases almost a decade ago. They were the same but with a leading 'h'.

tasubotadas• 4 years ago

What a pleasure was to use Mercurial.'

mikece2• 4 years ago

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.

iggldiggl• 4 years ago

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.

8n4vidtmkvmk2• 4 years ago

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.

mitjam2• 4 years ago

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.

nsenifty• 4 years ago

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.

mitjam2• 4 years ago

Yes! That was actually one of the reasons why we used it, too. Ist looks like Breezy, the friendly successor/fork still supports this.

tpoacher2• 4 years ago

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.

josephcsible• 4 years ago

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.

tpoacher2• 4 years ago

Absolutely. Just at a different cost.

mixmastamyk5• 4 years ago

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.

arunc• 4 years ago

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.

Hg Init: A Mercurial Tutorial

Related Stories