1. 21

This is the start of a daily series in the run-up to Christmas where I learn mercurial. This first post will be about what’s making me want to do this in the first place.

  1.  

  2. 8

    Hope you enjoy your mercurial experience! If you get stuck, mercurial’s online help is really good, much more readable than git’s manpages. There are also some really nice topics you can search for in the help, I’d suggest “hg help revsets” to start :)

    If you run into trouble or just want to chat about hg, the #mercurial IRC channel on freenode is active and generally welcoming to questions from new mercurial users.

    Oh also you should edit this post and click the check mark indicating you authored the content.

    1. 1

      I’d suggest “hg help revsets” to start

      great idea, will do :-)

      Oh also you should edit this post and click the check mark indicating you authored the content.

      I thought I did when posting. Thanks for pointing that out, fixed now!

      1. 2

        I’d also like to extend an offer to help!

        If I see you around #mercurial, I’ll do my best to be helpful.

        edit: Wait, I just recognised who you are! Hi Kamal! If you ever wanna hang out IRL and chat hg I’d love to as well.

        1. 1

          :wave:

    2. 2

      Regarding your question on Hg-Git interop (ie. using hg as a Git client) I’d be a bit wary of it. I’ve been using it for years now but recently there’s been a regression where the Git changeset mapping changed (see here). This means in practice that if you’re using hg-git 0.8.12 vs 0.8.11 you might not be able to clone or pull with the previous or future version of hg-git as the clone/pull will fail with a changeset not found. I’m sticking to 0.8.11 for now, but what I’m worried about is the lack of feedback and support, as shown by the open issues list. Aside from that, I switched from git to hg two years ago and whenever I got back to git I find it quite clumsy and unintuitive in comparison. The simple fact that you can identify revsets by number makes it much easier to use. I’m looking forward to reading the rest of your hg advent experience!

      1. 1

        Unfortunately hg-git is thousands of lines of leaky abstraction. There are tons of corner cases and fixing one breaks others. I wouldn’t advise using it due to issues like this. In the future there are plans to write an hg client that uses the git data store, so you’d have hg working directly with a git repo with no need for a conversion step.

        1. 1

          Interesting! Do you mean plans by the Hg core team or some other organization? I’m curious to know how Hg’s repository model, including phases and changeset history would be stored stored in a Git backend. The other thing that seems difficult would be to allow existing extensions/plugins to work transparently. I’m personally happy with how hg-git works (it’s mostly read only in my use case, pull from git, but don’t push), but am just getting a bit worried about the lack of maintenance.

          1. 1

            The lack of maintenance is caused by hg-git being a leaky abstraction. No one wants to spend time thinking about it. I believe the current reluctant maintainer also recently had a baby and has less time to focus on hg-git maintenance.

            The last time I heard the hgit (hg with the git data store) plan come up it was from Augie Fackler (@durin42). I don’t think any organization is backing it.

            1. 1

              I see, thanks a lot for the details! Hopefully this won’t crumble to bits in the near future – that would be bad for Hg interop, and I’d love to see more people use Hg over Git.

              1. 1

                This is really interesting to me considering my second post. Is there a place to find out more about it, or to at least hear about more when there is more to be heard?

                1. 1

                  The IRC channel.

                  1. 1

                    Excellent motivation to join!