1. 57
  1.  

  2. 16

    \o\

    /o/

    \o/

    This makes me irrationally happy. I didn’t think @SirCmpwn would accept this, and I’m so happy to be proved wrong.

    As soon as I have the money for it, I’m gonna buy a subscription.

    1. 6

      That’s enough for me to throw money at sr.ht. I can’t wait to try it out over the next week. If it’s solidish, I’ll go for the $5/mo plan in a heartbeat.

      1. 5

        pijul.sr.ht next? :)

        1. 2

          It appears that patches are welcome, so we just need a champion to do it, if it really can be done.

          1. 2

            I would say pijul itself needs some heavy work before thinking about its integration with sr.ht.

            1. 2

              Yeah, I really want Pijul to be an option, but it’s in practice been sufficiently buggy/slow that I’m sticking to Mercurial as my personal VCS. I think that’s gonna need to be fixed first.

        2. 8

          I’ve had to work a bit with mercurial over the last few months, and I really don’t get it’s appeal. It seems like git-lite, but it’s written in Python – somewhat contradictory, imo? Does anyone here have better experiences, or could give real-life examples where you used, e.g. Git and thought to yourself “I wish I was using mercurial”?

          For example, compared to Fossil, I get the benefits: everything is stored in one sqlite file, allowing atomic transactions. Repositories may have integrated wikis, forums, etc. and there’s a built-in web interface by default too. It’s different, what makes it interesting. Hg just seems too similar…

          Edit: To clarify, I’m not saying hg shouldn’t be used, or that it’s bad. I was just wondering about it’s major differences to git.

          1. 26

            Here’s a list of Mercurial features that I think are really cool:

            • Revsets – a domain-specific language for querying your commits
            • Templates – a domain-specific language for altering the output of almost every command. Putting together these two you can do things like this.
            • Evolution – a distributed and safe way to share rewrites (think automatically recovering from upstream rebase without any git reset --hard and no git push --force).
            • Absorb – automatically amends an entire stack of WIP commits at once by picking the right diffs from your working directory based on which commits’ contexts they fit best.
            • Curses interface for hunk-picking – a unified interface for splitting diffs for any purpose: whether to revert working-directory changes, write a new commit, uncommit parts of a commit, or amend a commit with more diffs. Just add --interactive to any of those commands and start picking hunks!
            • A fairly rich built-in web interfacehg serve and point your browser to http://localhost:8000 and you’re good to go.
            • Lots of support for monorepos – indeed, this is the main reason that Google, Facebook, and Mozilla are all pouring work into hg and are using it.
            • A consistent UI – this one is more subjective but often-touted feature of Mercurial. If a command accepts a revision/hash/tag/bookmark; it always uses the -r/--rev flag for it (and you can also always use a revset for any command that accepts a revision). If a command allows hunk selection, it always uses the -i/--interactive flag for it. The help for every command fits in about a screenful.

            Give it a try! Mercurial is neat!

            1. 4

              Nice Summary!

              From my perspective two things are really important:

              • Easy to write and rich plugins, distributed configurability, and generally much better windows support is a major consideration when introducing a DVCS into a larger organization.
              • Evolve. This is a really fresh approach to the end-user workflow. When you get out of Git mindset and switch to evolve things get really exciting.

              It’s also great that Mercurial was added into sr.ht. Lack of tools and solutions if hitting Mercurial for years now. Having something new makes me happy.

              1. 2

                Give it a try! Mercurial is neat!

                I did, but it was weird (to me, I’m not saying it’s generally bad!), since I’m not used to it. The documentation seems to be all over the place. Could you recommend a starting point for someone coming from git?

                1. 5

                  Not that I’ve ever made enough progress against my own git bias, but @sjl has some blog posts (http://stevelosh.com/blog/) worth checking out or Gregory Szorc’s posts (who has lots of experience with git and hg).

              2. 14

                (disclaimer: I’m the one who worked on this hg.sr.ht with @SirCmpwn)

                There are many things that have alternatives, and having alternatives is generally a good thing. I appreciate Mercurial for its more friendly CLI (I have to lookup Git man pages a lot more), better cross-platform support (although Git has gotten better lately), revsets language (as @ngoldbaum pointed), extension ecosystem (I myself wrote a couple of extensions that make my life easier), template language (to make output pretty the way I like), and phases/changeset evolution. Of course it also has downsides compared to Git so really YMMV as they say.

                But yes, if you use Mercurial the same way you use Git, it will definitely feel inferior (and vice versa). And if you stick to the basic minimum (clone/commit/push/pull/resolve, maybe a bit of rebase and branching here and there) then they both look so similar that you might wonder why both exist at all.

                1. 5

                  As I mentioned in my edit above, I’m not saying adding this was wrong in any way. It was more of a curious enquiry as to why people here like hg.

                  Considering that 95% of everything I do with Git nowadays is mediated by Magit, most of these features seem less important to me. Revsets seem interesting, but it doesn’t seem to be something that’s only possible due to an intrinsic architectural decision behind mercurial, or am I wrong. Any git porcelain could implement such a thing, as far as I understand what it’s about.

                  But you’re probably right, since I was only using “the bare minimum”, and then had to do something more than that (accidentally pushed a commit I didn’t want to), I was frustrated, since I was thinking in git-mode, and couldn’t find the documentation to quickly fix the issue. But the same would have happened if I was a regular-hg user that had to switch to git temporarily, so it’s quite meaningless.

                  1. 4

                    Oh yeah, nothing prevents Git from implementing revsets fairly easily – and people on the #mercurial IRC channel were just saying it would be great if Git could steal that idea from Mercurial, among others. I mean that’s the whole point of having alternatives, each one can steal the other ones’ ideas.

                    I also find the Mercurial documentation hard to navigate (although thankfully I don’t need it too much since the CLI docs make enough sense to me). The online Git documentation is much better IMHO.

                2. 7

                  It seems like git-lite

                  Mercurial is not meant to be a Git-lite, nor was it even ever meant to replace Git. Instead, Mercurial and Git were both designed to replace Bitkeeper. They differ a month in age, and are based on the same commit DAG model; you could say they grew up together.

                  Does anyone here have better experiences, or could give real-life examples where you used, e.g. Git and thought to yourself “I wish I was using mercurial”?

                  The most recent time I used Git and thought ‘I wish I could use Mercurial’ was last Tuesday, when I had to explain to a merging colleague how to get a copy of a file (not modify the existing one) as it was in an older commit. I know the answer, I thought, I already know the git show command! So I ran, from the same directory as the file,

                  git show abc123:myfile.ipynb > myfile-abc123.ipynb
                  

                  and got

                  fatal: Path 'src/myfile.ipynb' exists, but not 'myfile.ipynb'.
                  Did you mean '232279:src/myfile.ipynb' aka '232279:./myfile.ipynb'?
                  

                  . So instead I had to run

                  git show abc123:./myfile.ipynb > myfile-abc123.ipynb
                  

                  . Most Git commands assume paths are relative to your current working directory — but git show instead assumes paths are relative to the repository root, unless they start with an explicit ./. Because of the syntax inconsistency, knowing the command was not enough to use it correctly. That made me think ‘I wish I could use Mercurial’.

                  PS: my colleague didn’t ask why git checkout and git show are different in how you specify the revision. I wouldn’t have known the answer.

                  git checkout myrevision -- myfile  # revert file to old version
                  git show myrevision:./myfile       # print old version to stdout
                  

                  In Mercurial, for comparison:

                  hg revert myfile -r myrevision  # revert file to old version
                  hg cat myfile -r myrevision     # print old version to stdout
                  
                  1. 3

                    For years I used Mercurial, mostly for personal projects, or small scale ad-hoc collaborations.

                    My points:

                    • Python means good, portable unicode support for commit messages and comitter names.
                      In an international team and in the 21st century this is a must for me. With git I still see broken characters even for latin characters in comitter name. The american cultural imperialism prevalent in IT/CS in the sentence “just use ASCII” is unacceptable to me, and I still encounter this especially in UNIX circles.
                    • Web interface presented by hg serve is the same as the one used for remote push/pull operations.
                      with small collaborations sometimes with limited internet connections having both a web interface and remote push/pull working with zero effort is a killer imo. Also it is a nicer implementation to have a repo as http://my/repo , but with git for clone you usually have http://my/repo.git and web interface of your choosing at http://my/repo.
                    • the UI s far more convenient than git’s. The index in git, stateful commit preparation simply does not make sense to me. I can do that in a GUI where I see diffs inline. It could have been done with a different helper tool for git, but having it in the git command does not seem logical/convenient to me.
                      the git command arguments are totally convoluted, they are not organized in a single universal way, or at least I cannot comprehend that. hg commands have nice CVS like short aliases, and this makes working with hg convenient for me. I have git aliases on my machine but when trying to help someone else I always find them missing.

                    I’m a bit sad that git became the defacto standard, as I personally found hg more convenient and suitable to the workflows I use. I think the main points cited as git’s benefits are al bad practices, though I can accept that someone has a workflow where those are handy. In the PR based workflow with squash merges which I prefer hg and git are equivalently suitable.

                    1. 3

                      Whenever I have to dig out something from history in git I wish I had revsets: https://www.mercurial-scm.org/repo/hg/help/revsets

                      Git has about a million options to log to do the ~same thing, but almost every mercurial command accepts revsets, so you can use them all over the place. Say I want to rebase the commits on this branch that had this author but not this author onto this other branch. With hg it’s easy, with git I think I might need a shell script.

                      1. 1

                        but almost every mercurial command accepts revsets, so you can use them all over the place

                        Ok, that sounds neet, I have to say. But I don’t see why git couldn’t do the same?

                        1. 2

                          It totally could. They just haven’t yet.

                      2. 1

                        I think it’s entirely personal preference. There are tons of arguments online about why each is slightly better than the other, but in practice they’re virtually equivalent.

                        It seems like git-lite, but it’s written in Python – somewhat contradictory, imo?

                        Not sure I understand what you mean there.

                        1. 3

                          Not sure I understand what you mean there.

                          Maybe it’s just be, but when something has to be lightweight, it shouldn’t be running in an process-based interpreter, but should be compiled. But that’s just my view.

                          1. 3

                            There is some work to move parts/most of mercurial to rust see: https://www.mercurial-scm.org/wiki/OxidationPlan

                            Also, Mercurial existed before git did. Linus decided against mercurial mostly because it wasn’t “fast enough” for his use case, the linux kernel tree. So he wrote git, instead of just speeding up mercurial.

                            1. 8

                              Also, Mercurial existed before git did. Linus decided against mercurial mostly because it wasn’t “fast enough” for his use case, the linux kernel tree. So he wrote git, instead of just speeding up mercurial.

                              It depends what you mean by “exist”. The git prototype came before hg, but hg was self-hosting before git. The details can probably be excavated from the LKML, but I remember there is like a one-month gap between the first mention of git followed by the first mention of hg.

                              Matt Mackall, original author of hg, chose Python because it let him build an interface quickly. Linus was never particularly bothered about an interface, so he just built the data structures out of C and shell. For a long time, the only way to build a git commit was to run a bunch of ad-hoc shell scripts in turn for creating blobs and trees.

                              1. 7

                                For a long time, the only way to build a git commit was to run a bunch of ad-hoc shell scripts in turn for creating blobs and trees.

                                For a git n00b like me, it feels like not much has changed in that regard ;)

                      3. 3

                        Wonderful! I’ve just created an account and uploaded my ConTeXt month calendar generator and my dotfiles to try it out. (Links not for self-promotion, but so that anyone curious can click around and see what this alpha build looks like.) Can I just say that it feels surprisingly wonderful that the pages load (for me) in 500 mostly-response-time milliseconds (feels like less), instead of Bitbucket’s 3 mostly-AJAX seconds (feels like more)? I had forgotten how fast the Web should be.

                        1. 1

                          awww, yeah! I’ve been wanting to get into mercurial and now I have ZERO reason not to.

                          1. 1

                            aw yeah.

                            hg is awesome

                            1. 1

                              [Comment removed: I replied in the wrong place.]