1. 1

    Also for self-hosted there’s https://rhodecode.com CE which has similar source distribution like Gitlab (Free CE vs Paid EE editions)

    1. 1

      There’s a free (as in freedom) fork of it too: https://kallithea-scm.org/

    1. 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 ;)

                  1. 17

                    I’ll stick to gitlab, new exciting features coming out every month. I can self host. I love gitlab’s CI system that is built in as well. I can now do chatops easily with mattermost.

                    1. 16

                      An important reason I use GitHub is for the “network effect”. Everyone and their dog is on GitHub, so it’s just practical.

                      If I had my say, I’d still be using mercurial and BitBucket. But at some point someone “forked” my repo by converting it to git and uploading it to GitHub with their fix (I found out accidentally a year later), so then I decided to just migrate my stuff to GitHub.

                      Especially for my personal stuff, the differences between GitHub, GitLab, BitBucket, etc. aren’t large enough to warrant losing sleep over, so I just opt for the most practical solution.

                      1. 5

                        I use Gitlab at work where it was kind of a hassle to deal with in the beginning but since about 1.5 years it became a great product which I really like to use. As you already said, the integrated CI system is great if not the best I’ve ever used. We also have some Mattermost integrations for chatops which were straightforward to setup.

                        1. 4

                          Has its performance gotten better? Every time I’ve tried gitlab its performance and hardware resource requirements have been a blocker.

                          1. 4

                            With limited hardware resources I would recommend something like gitea. Gitlab is running on a beefy machine at work so performance is not a problem.

                            1. 1

                              I’d love to see a gitea for mercurial.

                              1. 2

                                For Mercurial, Both Kallithea and RhodeCode can run fine on a box with 1CPU and 1GB of ram not even needing database installed as they could run on SQLite.

                        2. 3

                          I also use GitLab and I’m content with its CI, or I was until recently. but I find it confusing, and more than version control and CI, it aims to become an all-in-one solution much like Azure Devops (Formerly Microsoft Team Foundation Services).

                          I understand that this is a strategic goal for them, they develop in that direction, I’m okay with it.

                          As a user I have not logged in for a few months, log in, create a new project to get a CI pipeline, and I’m overwhelmed with UI changes, something something Kubernetes… complexity and unneded feature relatd changes and options everywhere. I1m not their target audience anymore, and they may loose me very soon, as I don’t have the resources to re-learn their platform every few months to be able to disable unneeded features.

                          1. 3

                            I can understand your frustration they do through a lot of new features at you. Personally I’m a sysadmin that also writes a lot of code. My sysadmin side gets excited with all the new features that are built into a nice contained solution for us.

                        1. 3

                          Great news. We upgraded our 16.03 package based nix deployment to 18.03 and nix 2.X series. That was a surprisingly easy task given our installer complexity and nix usage.

                          1. 4

                            There’s one interesting service called https://littlebirdie.io/ it’s also doing a similar thing as f5bot, but live and to slack. We created this for our internal team to scan the internet for mentions.

                            1. 5

                              I’d love to read their post-mortem. They failed at like all possible steps :D

                              1. 24

                                They appear to have quite a successful business selling multiple locks to infosec bloggers.

                                1. 2

                                  God, that’s brilliant. Just continually create minimal IoT products and trick bloggers into tearing them down after buying them.

                                2. 3

                                  Sure the execution was badly done, but the entire concept was appalling to begin with. Adding fragile battery-powered electronics to a padlock is already pretty stupid. Adding a radio-frequency attack surface to that is stupider. But putting the whole thing on the internet is really the cherry on top. Who the hell buys these products?

                                  I hope the ridicule this story generates helps a little more of the general public see the implicit “Id” prefix in front of “IoT”.

                                  All that said…. remember when one of the world’s most reputable bike-lock makers got embarrassed to the point of recalling multiple product lines, all because of a PoC video featuring a Bic pen? Shit happens, in the consumer lock biz no less than anywhere else.

                                  1. 1

                                    Well, there’s this, but it’s disappointing. David Tao fucked up massively, and his professional credibility will suffer massively if he doesn’t fix it quick.

                                  1. 8

                                    Contrary to most opinions I think that acquisition might be a good thing:

                                    • Microsoft is a different company now their open source strategy recently is quite good.
                                    • Github seems in decline for some time, the inability to lock a permanent CEO, low number of new features
                                    • MS has all the resources to put Github on the next level if they don’t screw it up.

                                    What could be bad is if MS buys Gitlab, then they would control that space. Gitlab is also a heavily VC backed so investors will seek for an exit at some point.

                                    1. 10

                                      Honestly, my hope is that the fear factor of this, convinces more people to consider alternatives.

                                      I’ve setup gitlab (a few years ago) for a client, and it was a fucking pig. I’ve looked at your solution too, and wasn’t completely sold on some aspects of it (sorry, dont remember what right now) - but these things obviously work for some people, and getting out of this mindset that “GitHub is just what all developer use” is crucial to me.

                                      Monoculture should scare people a lot more than the boogey man from Redmond.

                                      This line from the Bloomberg article sums up the issue:

                                      San Francisco-based GitHub is an essential tool for coders.

                                      This is honestly like claiming “Windows is essential for technology companies”.

                                      1. 13

                                        Microsoft is a different company now their open source strategy recently is quite good.

                                        I’m getting awfully tired of people saying there’s nothing to worry about because they’ve been nicer for the past handful of years. They have been antagonistic to free software for decades.

                                        Microsoft changed their tune because it became profitable to do so. If it becomes profitable to be dicks again, they will be dicks again.

                                        I’m glad we have a kinder, gentler Microsoft. Don’t kid yourself about their motivations.

                                        1. 10

                                          Also good to remember: they still routinely attack Linux and related free software by threatening with their patents, and extract patent royalties from many terrified companies who use Linux

                                          1. 4

                                            They’ve collected over a billion dollars on Android alone.

                                          2. 1

                                            I never said to not worry about. I’m writing this based on a feeling MSFT will do good with Github. Time will show, and their motivation is quite simple, buy more power and make more money.

                                          3. 1

                                            That would be very cool that as @nickpsecurity mentioned, RedHat take a shot at gitlab.

                                            1. 3

                                              Given the high performance has for on-premise installations, that would be a great addition for RedHat, TBH.

                                              (I see GitLab, even paid, everywhere at clients and I have yet to see a GH Enterprise installation in the wild)

                                              1. 3

                                                Riot games had GH enterprise a few years ago, just for their web team. The rest of the company was using perforce.

                                                1. 2

                                                  I’ve got the opposite experience. I’m seeing big installations/companies use GHE all the time, and none of them Gitlab.

                                            1. 4

                                              I’d said it again:

                                              Contrary to most opinions I think that acquisition might be a good thing:

                                              • Microsoft is a different company now their open source strategy recently is quite good.
                                              • Github seems in decline for some time, the inability to lock a permanent CEO, low number of new features (They have already a plan to put a new experience CEO from MS.)
                                              • MS has all the resources to put Github on the next level if they don’t screw it up.
                                              1. 1

                                                The 2 submissions were merged. Your comment is now a double-post.

                                              1. 5

                                                this full-throttle tinfoily panic mode of some people right now. “move to hosted gitlab!!1 that will show ‘em!!11”. i’m not anti-gitlab, but hosted gitlab has the same set of problems like github. like, for example, being bought by $EVILCOMPANY

                                                if microsoft now decides there will be no more free repos, it’s ok! they can do with their property however they please (just like before that acquisition github could’ve done). don’t bitch about the free lunch not tasting right. that is the deal if you use resources of others for free.

                                                1. 3

                                                  I think for most people, if gitlab took a similar turn, a self-hosted (or pay someone else to host it) OSS version of GitLab would be fine.

                                                  People use gitlab.com because it’s hands-off, not because it’s the commercial version for free.

                                                  1. 3

                                                    It’s not “that will show em” at all. No idea where that is being quoted from.
                                                    I can say my statement was, IF the MS acquisition bothered you, and there is enough historical precedent that it may reasonably do so for reasonable people, then note that Gitlab does currently have 1-click repository migration from GitHub. In addition that is is also a possibility that Github may unilaterally sever that capability IF the migration becomes a flood. Ergo if you are going to do it, then do so now and don’t wait.

                                                    1. 1

                                                      it was a purposely overstated made-up-quote (easily spotted by the liberal use of “!!111”).

                                                      microsoft is an actor on the market and as a result does things to maximize profits. one only has to take that in account when choosing to use their services. i’m not overly happy with it either, but gitlab is an actor too and plays by the same rules, including the possibility of being acquired. just self host, it’s not even hard, scaleway has prepared images for that for example.

                                                      regarding the importing functionality: if they break the mechanisms to do that, i guess many other things won’t work as well, like bots acting on issues, etc. i don’t think they will break the whole ecosystem, as effectively that’s what they’ve paid for. maybe they’ll do that in the extended future, like twitter breaking their api for clients.

                                                    2. 2

                                                      Imagine what would happen when MSFT after buying GH also gets travisCi , which i believe they will do :)

                                                      1. 2

                                                        It should also be quite a bit cheaper, afaik they never took VC money.

                                                    1. 9

                                                      I run a couple of hg servers too. It’s pretty easy to do, and the docs give a good run down of how to do so:

                                                      https://www.mercurial-scm.org/wiki/PublishingRepositories

                                                      While we’re diversifying away from github, let’s also diversify on VCSes. :-)

                                                      1. 1

                                                        Do you just use ssh+hg on a private server, or use a ‘package’ (ala gitlab, but for hg)?

                                                        Not looking for a suggestion so much as appraising actual usage for a potential OSS project.

                                                        1. 1

                                                          I use ssh+hg; haven’t yet had to host a server for a large amount of people were manually managing ssh keys wasn’t a possibility.

                                                          But yeah, improving Kallithea or Rhodecode or giving gitlab hg support would all be great things.

                                                          1. 1

                                                            Right - so my plan was actually a more (in my mind anyway) natural progression from what it sounds like you’re using now.

                                                            Effectively:

                                                            • rely on the system ssh still, either direct as you’re using it for small installs, or via LDAP for larger/multi-server setups
                                                            • rely on Filesystem ACL’s to allow group based write access to repos
                                                            • use a vcs-specific “shell” for Git, Hg (heck even SVN) sessions

                                                            To clarify on the ‘improving’ topic:

                                                            • RhodeCode is AGPL or commercial. That isn’t going to fly.
                                                            • Kallithea is GPL. That isn’t going to fly.
                                                            • Gitlab is IMO a Rube Goldberg machine at this point. The number of services required is crazy.
                                                            1. 3

                                                              The AGPL is flying quite well in Mastodon. People have been scared of copyleft forever, and great copylefted things have flown.

                                                              The constant push back against copyleft is how we got github in the first place: hosts all of the code, shows none of its own.

                                                              1. 3

                                                                Right, I understand the premise but given that (a)gpl gives rhodecode inc exclusive permission to do a GitHub (which they do, via the enterprise edition) I have zero incentive as either a developer or as a business owner to contribute to that project.

                                                                Everything I create (as opposed to forks) is bsd-3-clause, specifically because I see the main targets for things like this as being small/medium business.

                                                                1. 1

                                                                  The only reason it gives them “exclusive permission” is because people like you are afraid of touching the AGPL for no good reason. It’s the fear around the AGPL that does it, it’s the very same undermining of copyleft.

                                                                  Small/medium business can use AGPLed stuff; it’s not the cancer that people said the GPL was in the late 90s. It’s not some kind of plague to avoid. Rhodecode is abusing that plague fear that others have created.

                                                                  1. 1

                                                                    rhodecode inc is able to produce an enterprise edition with closed source additions.

                                                                    No other entity on earth can do the same thing, either hosted or distributed, because any changes they distribute must be returned upstream.

                                                                    How is that not exclusive permission.

                                                                    And frankly the gpl is a cancer. Good companies contribute back to/release permissiviely licensed projects.

                                                                    Shitbag ones are unlikely to do that regardless of the license.

                                                                    1. 3

                                                                      Interesting discussion on this topic. We’re actually in the process of changing AGPL for RhodeCode CE edition into MIT/BSD. We did the same move with our other project already - RhodeCode-Appenlight.

                                                                      MIT+CLA works fine for Gitlab. We believe this will help RhodeCode, and we’ll execute on this very soon.

                                                                      1. 1

                                                                        I don’t know if you have much content that would fit lobste.rs, but it’d be great to see blog posts or something here about RhodeCode.

                                                                        Also, does RhodeCode support FreeBSD?

                                                                        1. 2

                                                                          We do occasionally post release notes. Lots of our stuff doesn’t fit lobsters and it felt kind of “too much marketing” But if there’s something related to Mercurial, e.g evolve support or narrow support (which is supported by 4.12 release) we’ll post it here for sure.

                                                                          FreeBSD is supported if you run rhodecode from source. Afair installer have some problems because of older NIX we used.

                                                                      2. 1

                                                                        You can make private modifcations to AGPLed code. You can grab Rhodecode, modify it in-house, and you don’t have to distribute anything back to anyone.

                                                              2. 1

                                                                RhodeCode has full SSH Key management together with SSH access in the Free CE edition since few releases.

                                                                Source code here: https://code.rhodecode.com/rhodecode-enterprise-ce

                                                          1. 4

                                                            Thanks for posting this.

                                                            A general problem I have with mercurial (I started using it for pet projects I work on at home, never at work), that a lot of material you can google is fairly old and lots of it outdated. Whenever someone refers to a hg extension, one needs to further investigate if this extension is still alive, and still the prefered way of doing things.

                                                            1. 1

                                                              The feature that this article describes is in core.

                                                              1. 9

                                                                Just to elaborate, because this is the third or fourth Mercurial discussion coming up in as many days, and I’m getting tired of the same discussion happening ad nauseam:

                                                                1. Out-of-the-box, with no configuration done, Mercurial doesn’t allow editing history–but ships with all the functionality required to do that. You just have to turn it on. Turning it on takes up to three lines in a config file and requires no third-party tools whatsoever.
                                                                2. Out-of-the-box, Mercurial does come with phases (discussed here) and the associated phase command that allows explicitly altering them. You don’t actually use the phase command that much; phases are actually more for consumption by history editing commands.
                                                                3. If you enable any of the history editing extensions–again, which ship with Mercurial–including rebase, which is probably all you need, and histedit, if you do really need the equivalent of git rebase -i, you will find they are phase-aware. In particular, they will allow you to alter changesets that are secret or draft, but not public. Because changesets will become public on push by default, this is by itself awesome, as it can trivially help you avoid accidentally rebasing something someone else might’ve pulled. Having this would’ve eliminated quite a few Git horror stories.

                                                                All of the above ships in core. You need to add at most three lines to your .hgrc or equivalent to get all of it. Which is fine, because you also need at least two lines just to set your email and name, much like you’d have to at least do git config --global user.email and git config --global user.name. A couple extra lines isn’t a big deal.

                                                                The only thing interesting in this space that doesn’t yet ship in Mercurial, and which I’m really excited about, is something called changeset evolution, which will allow cleanly and easily collaborating on in-progress, frequently-rebased/collapsed/edited branches. But that’s not baked yet, and Git doesn’t have anything equivalent to it yet anyway.

                                                                1. 5

                                                                  The problem is making it clear to new users or users coming from git how to enable those extensions. There’s also the problem that the new tweakdefaults option is trying to solve: that hg’s backward compatibility guarantees mean that new features (e.g. new since hg 1.0) don’t get surfaced in the hg UI unless you’ve customized your setup (or had it customized for you as in a corporate setup).

                                                                  git’s out-of-the box experience enables a lot of power user features. This certainly isn’t great for safety but it is great for discovery - thus these perennial discussions on forums like lobsters and HN.

                                                                  I’m hoping with evolve getting upstreamed we might see more projects using mercurial. On the other hand, for open source projects the only real place to host them is either to use hgweb and roll a custom hosting and development workflow (basically what mercurial itself does) or use bitbucket, which is run by people who don’t prioritize or think much about open source fork-based workflows. It would be amazing if there were more competition in this space. Kallithea doesn’t support pull requests. Rhodecode has a questionable past participating in the free software community. I’m not aware of much else in this space.

                                                                  What would really change things is if one of the big players like github or gitlab decided to add support for other VCS tools although I’m not exactly holding my breath for that to happen.

                                                                  1. 4

                                                                    Unfortunately, I agree. I have noodled with basically rewriting Kiln (only not called that because I’m not at Fog Creek) based on changeset evolution and with an explicit fork-based workflow focus, but I’ve been waiting to see if evolution really does get fully into core, and then what the story is with hg absorb, since properly supporting Mercurial and evolution looks really different in an hg absorb-based world than one without it.

                                                                    In particular, my idea is that anyone can push to a repository, but it’ll automatically go into a new pull request in draft phase. At that point, if hg absorb stays a thing, and a normal user can be expected to just run hg absorb repeatedly as they address issues, then I can rely on obsmarkers. Otherwise, the story empirically gets a lot more interesting; I’ve had trouble on prototypes not requiring the user to know they’ve got a custom branch, basically doing the same kluge as Gerrit, albeit with a different mechanism.

                                                                    Edit: just to be clear, I’ve prototyped bits of this a few times, but nothing I want to release—doubly so since it’s all in Smalltalk anyway. But it’s been helpful to try to think through what a proper approach to this would work like.

                                                                    1. 2

                                                                      AFAIK the only blocker on absorb getting upstreamed is the need to rewrite the linelog interface in C.

                                                                    2. 2

                                                                      I’d like to add that RhodeCode is actively supporting usage of Evolve/Phase with changeset evolution. Based on feedback from our users we started to ship evolve extension enabled and within the CE and EE editions.

                                                                      This works with Pull requests, can be enabled globally or per repository.

                                                                      You might question the past, but we since almost 2 years provide a open-source free, no limitation version of CE edition of RhodeCode (similar to Gitlab CE/EE). You can use evolve there and it works :) I said it many times, and I’ll said it again. We did mistakes with certain past releases, but currently, our business model is based on a free GPL open-source version. This will be here to stay, we always try to promote Mercurial, and it’s great workflows using mentioned extensions.

                                                                      I doubt Gitlab/Github will ever support mercurial. They openly said they won’t for many reasons.

                                                                      We currently work on a simple app for Digitalocean, we hope it’ll make usage of Mercurial hosting much easier for people that don’t want to host it themselves.

                                                                      1. 1

                                                                        Kallithea doesn’t support pull requests.

                                                                        Looks like they now do.

                                                                        I’m not aware of much else in this space.

                                                                        Phabricator, Redmine and Trac also support Mercurial as well.

                                                                        However none of them are as convenient as the hosted and “free for open source” offerings of Bitbucket, GitHub and GitLab.

                                                                      2. 2

                                                                        I feel the need to fork hg2k5, which will be mercurial with only the original features. :)

                                                                        1. 2

                                                                          You’d have to start with forking Python 2.4 so that you could run it.

                                                                  1. 1

                                                                    TWe’ve got a similar problem at RhodeCode when we generated archives from git/hg repos. At the beginning we’ve got reports about hash changed of generated archives files, but we found that was the archiver added some metadata files with current date inside. Then we fixed that and used similar logic from Mercurial to create archives from all files inside a repository at particular commit. This resulted in stable archives with same hash every time.

                                                                    You have to use a consistent pointer via commit to guarantee that.e.g http://server.com/repo_name/archive/a9611b8be70e3dfafdd91d3e64c6636945277636.zip

                                                                    Our implementation is slower because it requires creating zip files via python code, and iterating all files in the repo, but combined with archive caches it’s good enough.

                                                                    1. 1

                                                                      I really like his workspace idea. I’ve sent one patch to three or four projects; there’s no need for me to have a whole clone of them up on github gathering dust.

                                                                      1. 1

                                                                        Would a PR from diff patch would be an interesting concept here ?

                                                                        1. 1

                                                                          Can you elaborate? I’m not sure what you mean.

                                                                          1. 1

                                                                            To this day, I’m surprised this isn’t a feature. I often only make one or two changes to a project, and would be happy to just push the refs (or create a patch) rather than forking and remember to garbage collect later.

                                                                        1. 6

                                                                          Great write up. I’d wish now for a Mercurial problem summary from him now just to lear what are the key problems in his opinion.

                                                                          1. 9

                                                                            Using nix to distribute RhodeCode was the best decision we made for how we distribute our software. It removed all problems we had with python packaging just using virtualenv. I think the key benefit is that our installation survives system upgrades while we had almost 40% failure rate in this case with previous virtualenv based installer.

                                                                            1. 5

                                                                              Would you be interested in doing a whitepaper?

                                                                              1. 3

                                                                                Do you instruct end users to use Nix, or do you have some custom installer that somehow hides Nix from the users?

                                                                                1. 5

                                                                                  We abstract it. End users just run a single binary that creates full nix env, and unpacks all dependencies into a custom nix store.

                                                                                  Nice things are that on upgrades we still have the full tree of old dependencies, so, for example, rollback to the previous release is just swapping a symlink.

                                                                                  1. 1

                                                                                    This reminds me of the guix pack command: https://www.gnu.org/software/guix/blog/2017/creating-bundles-with-guix-pack/

                                                                                    Would something like that (e.g. ported to Nix rather than Guix) make life easier? I imagine that including Nix itself in the artefacts you distribute would make things quite bloated. (I’ve never used Guix, but I’m a big Nix fan :) )

                                                                              1. 16

                                                                                I seem to be the only person who moved from git to mercurial and liked git a lot more.

                                                                                Here were my impressions:

                                                                                • The index (“staging area”) is an awesome feature. I know it trips people up occasionally, but the ability to carefully and precisely stage some of the changes in the working tree is invaluable.
                                                                                • I like git’s branch model better than Mercurial’s. It’s more flexible and, at least for me, more intuitive. Maybe bookmarks are equivalent, but we didn’t use them at my work, so I couldn’t say.
                                                                                • I like git’s general acceptance of history rewriting. It’s a valuable feature without which you need to choose between committing very carefully or breaking bisect and having a useless history. If you’re worried about corrupting your history, back up your repository (which you should do anyway, history rewriting is not the only way to corrupt a repository). I know it’s possible in Mercurial, but it’s not a first-class citizen and the culture disapproves.
                                                                                • Mercurial’s commandline interface is a bit more uniform and predictable, but to be honest, this feels like a very weak benefit. If you’re using it professionally, muscle memory should basically mitigate the difference within at most a few weeks. Also, Mercurial’s interface certainly isn’t perfect, e.g. -l for commit limiting in hg log is wrong (it should be -n).
                                                                                1. 12

                                                                                  index (“staging area”) is an awesome feature.

                                                                                  hg commit --interactive or hg ci -i is essentially the same thing. What people generally like about the index/cache/staging-area (these were all official synonyms at one point) is the ability to selectively pick apart commits, not so much having an extra, semi-obligatory step between your code and the creation of a commit. With Mercurial’s curses interface, hg ci -i is pleasant and widely loved.

                                                                                  If you really want a cache/index/staging-area, you can use hg ci -i --secret to start a secret staging commit and hg amend --interactive or hg am -i to keep adding to it. The --secret part is just to make sure it doesn’t get pushed accidentally. Once you’re ready to show the world your commit, hg phase --draft will turn it into a draft that you can share.

                                                                                  I like git’s general acceptance of history rewriting.

                                                                                  hg has this too, but better, and not as well-advertised: there’s a meta-history of what is being rewritten. This is called changeset evolution. The basic idea is that there are obsolescence markers that indicate which commit replace which other commit, so that history editing can be propagated in a safe, distributed fashion. No more need to force-push everything and then tell everyone who may have been following along to reset branches. Just push and pull and hg evolve will figure out where everything should be because it has more context.

                                                                                  Mercurial’s commandline interface is a bit more uniform and predictable, but to be honest, this feels like a very weak benefit.

                                                                                  My father, may he rest in peace, used to say that people can get used to everything except hunger. Sure, you can get used to git’s widely-derided UI. But why should you have to? If we can come up with a better UI, we should. Indeed, alternative git interfaces are their own cottage industry. Don’t downplay the problems that the git UI cause.

                                                                                  1. 9

                                                                                    hg commit --interactive or hg ci -i is essentially the same thing.

                                                                                    No it’s not. I can (and frequently do) continue to mess with the working tree after adding changes to the index.

                                                                                    hg has this too

                                                                                    General, ecosystem-wide acceptance of history rewriting? Not in my experience. When I was using it, the general guidance seemed to be “don’t do that, but if you’re going to do it anyway, here’s how”, whereas guidance for git is more along the lines of “here are some things to be aware of when you do that, now have fun”. No remote solution I used would permit pushing rewritten history.

                                                                                    The very page you linked to says that evolve is incomplete.

                                                                                    To be clear, the workflow I’m looking to be enabled here is to commit and push extremely frequently—as often as I save, ideally—and then, once the feature is complete enough for review, squash all those mostly-useless commits together into a single or few meaningful ones. This lets me get both commits willy-nilly and meaningful, bisect-able history.

                                                                                    But why should you have to?

                                                                                    Because it took me like three days? “Not ideal” is a far cry from “compellingly bad”. I will certainly agree that git’s interface is not ideal, but Mercurial’s is not better enough to be a compelling feature on its own. (Also, I had to get used to Mercurial’s interface when I started a job that used it. Why did I have to?)

                                                                                    1. 9

                                                                                      No it’s not. I can (and frequently do) continue to mess with the working tree after adding changes to the index.

                                                                                      Have you tried hg ci -i? Combined with hg am -i, it really is the same thing. Creating a commit is, pardon the pun, no commitment.

                                                                                      The very page you linked to says that evolve is incomplete.

                                                                                      It’s sadly in a state of perpetual beta, but so was Gmail for about five years and that didn’t stop a lot of people from using it from day one. Evolve is mostly feature-complete, just not completely polished to the usual hg standards.

                                                                                      To be clear, the workflow I’m looking to be enabled here is to commit and push extremely frequently—as often as I save, ideally—and then, once the feature is complete enough for review, squash all those mostly-useless commits together into a single or few meaningful ones. This lets me get both commits willy-nilly and meaningful, bisect-able history.

                                                                                      This is exactly what evolve is for. And people can even pull your commits before they’re squashed and if they pull again after you squashed, they won’t even see the difference in their workflow. Their copy of the commits will also be squashed without them needing to do an extra step like git reset and try to figure out exactly what to throw out.

                                                                                    2. 4

                                                                                      I agree that the staging area is an unnecessary concept. As a self experiment, I made myself git aliases to not use staging. After a few months of using that setup, I can say that I don’t miss staging.

                                                                                      (I don’t use Mercurial at all)

                                                                                      1. 3

                                                                                        IMHO hg ci -i is a way better interface than git staging area even with -i. Used both, Mercurial one is way better.

                                                                                        However I just recently found that there’s a mercurial equivalent of hg -i for git too as a plugin.

                                                                                      2. 4

                                                                                        what benefit does the staging area give you that cannot be replicated by just committing the changes you would have staged and then doing a rebase to squash all the ‘stage’ commits into one main commit? I use this workflow a lot and find the intermediate stages cleaner and easier to work with than the git staging area.

                                                                                        1. 2

                                                                                          The index feels cleaner and if I wander away in the middle and forget what I was doing, it’s much easier to unwind.

                                                                                          Obviously, there are any number of workflows which provide equivalent functionality, and I doubt anyone can muster more than extremely weak objective support or criticism of any. Having used both git and mercurial, I strongly prefer having the index to not having it. If people push me on it, I’m sure I can rationalize that preference until the cows come home, but I’m not sure how constructive that would be.

                                                                                      1. 2

                                                                                        Glad to hear you’re enjoying Mercurial. Because I’m curious how they feel to a recent Git user: how do you like having local commit numbers that go 1, 2, 3, ... beside the usual unique hashes?

                                                                                        1. 3

                                                                                          I don’t use it that much but it is kind of nice to have a short hand, linear, way to look at the commits. Just talking about hash’s is pretty useless for anything other than knowing they aren’t the same.

                                                                                          1. 2

                                                                                            It’s nice to hear that you enjoy rev numbers, too. They are a detail, but one that I am fond of.

                                                                                          2. 2

                                                                                            Those numbers come in handy. E.g hashes don’t give you a perspective, you can tell quickly how big the project is looking at the numeric number, also comparing abcd...efgh vs 10...20 gives you much easier syntax to understand. Ofcourse this all applies only to local repositories because those numbers are relative

                                                                                          1. 4

                                                                                            If you don’t need hosted option but on-premise/private cloud you can check out RhodeCode which supports bookmark based Pull requests, Pull Request versioning, Mercurial evolve support.

                                                                                            Here’s our blog post on how to use bookmarks via Pull requests: https://rhodecode.com/blog/120/mercurial-workflow-using-bookmarks-how-to-setup-and-use

                                                                                            From our perspective using Mercurial to develop RhodeCode, a bookmark based workflow is a much easier to use than branches. And evolve/phases make it easier to simply rebase/reorder your commits, or fix small problems found during code-review.

                                                                                            1. 3

                                                                                              Evolve is one of the best feat. of Mercurial. We (RhodeCode) are shipping evolve extensions with fully enable per-repository support of it from the previous release.

                                                                                              What really surprised us is that lots of folks actually use it. We got lots of feedback and for sure we’ll update support for it.

                                                                                              1. 3

                                                                                                This article is great. Adds another area to think of when securing your company access.