[HN Gopher] Hg Init: A Mercurial Tutorial
___________________________________________________________________
Hg Init: A Mercurial Tutorial
Author : captn3m0
Score : 80 points
Date : 2022-07-21 06:55 UTC (1 days ago)
(HTM) web link (hginit.github.io)
(TXT) w3m dump (hginit.github.io)
| systems_glitch wrote:
| 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 wrote:
| 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 wrote:
| > "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.
| thfuran wrote:
| 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.
| aayjaychan wrote:
| 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.
| xeyownt wrote:
| Maybe some day we will have https://gitinit.hghub.io/
| mikece wrote:
| 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 wrote:
| Having used Mercurial at the time, I can strongly vouch for
| GitHub being a _massive_ draw toward using git. I 100%
| believe this narrative.
| srean wrote:
| 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.
| mikece wrote:
| 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 wrote:
| 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.
| bornfreddy wrote:
| 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.
| jjav wrote:
| 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.
| mikro2nd wrote:
| 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 wrote:
| 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/
| jefozabuss wrote:
| 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)
| vbernat wrote:
| 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.
| rubyist5eva wrote:
| standard branches can serve this purpose
| rr888 wrote:
| 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.
| speed_spread wrote:
| 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.
| felixthehat wrote:
| VS Code added that feature too recently, very nice addition
| https://code.visualstudio.com/updates/v1_44#_timeline-view
| nicoburns wrote:
| 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.
| guitarbill wrote:
| You can also use `git stash apply` (which doesn't pop the
| stash), followed by maybe merging, and finally a `git stash
| drop`.
| Cederfjard wrote:
| 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.
| nicoburns wrote:
| Yeah, working out which stash contains your work can be
| quite tricky though! As they are not named by default.
| aaaaaaaaaaab wrote:
| 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 wrote:
| 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...
| taspeotis wrote:
| https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...
| gilrain wrote:
| Yes, git is more popular than hg. Keen observation, there. /s
| moonchrome wrote:
| Mercurial just has better UX so less need to Google
| [deleted]
| newaccount2021 wrote:
| sio8ohPi wrote:
| 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.
| benibela wrote:
| The best UX has TortoiseHg
|
| Just click the Undo-Button: https://tortoisehg.readthedocs.
| io/en/latest/_images/commit.p...
| sio8ohPi wrote:
| Just from a quick read of the docs, isn't 'undo' just
| 'rollback' (dangerous, deprecated)? Can you undo an undo?
| LAC-Tech wrote:
| _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.
| nindalf wrote:
| 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^'
| BeetleB wrote:
| 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.
| sio8ohPi wrote:
| 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.
| wyuenho wrote:
| 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.
| hexo wrote:
| Hg: + another 2hrs of cleaning up disk space so it can
| "checkout" revision you actually care about
| faichai wrote:
| 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.
| JustSomeNobody wrote:
| 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.
| benreesman wrote:
| 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.
| rubyist5eva wrote:
| 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.
| aayjaychan wrote:
| 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.
| throw0101a wrote:
| > [...] _did I miss the git index._
|
| Perhaps:
|
| * https://www.mercurial-
| scm.org/wiki/GitConcepts#Git.27s_stagi...
| kej wrote:
| 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 wrote:
| How does that differ from tab autocomplete?
| deadwanderer wrote:
| 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 wrote:
| > 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
| gadders wrote:
| 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 wrote:
| 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 :)
| mitjam wrote:
| 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.
| tasubotadas wrote:
| What a pleasure was to use Mercurial.'
| TheChaplain wrote:
| Page mentions Subversion, anyone still using that vcs these days?
| albertopv wrote:
| oh yes...
| s_dev wrote:
| WordPress plugin deployment depends upon on Subversion
| dailykoder wrote:
| 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
| guitarbill wrote:
| 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
| BeetleB wrote:
| 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.
| m000 wrote:
| 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.
| mikro2nd wrote:
| 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 wrote:
| The OpenBSD project still uses CVS.
| georgia_peach wrote:
| 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...
___________________________________________________________________
(page generated 2022-07-22 23:02 UTC)