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

          2. 2

            You can think of the phases as totally ordered (secret → draft → public) and a commit’s phase can only move in that direction. That is, a secret commit can become either a draft or a public commit, a draft commit can become a public commit, and a public commit is “stuck” being public. (Obviously, Mercurial allows you to force a commit to any phase as well.)

            I hate when people say “obvious” or “obviously”. From that description it is not at all obvious to me why Mercurial allows you to force a commit to any phase. My first impression from that is, well then, that’s not much a feature if I can disregard it at any time.

            “Obvious” is so insulting. At best, you get some people nodding along and then a bunch of people also going “well, not sure what is obvious about that”.

            1. 4

              I personally read that more in the customer-service tone of “of course if you really want to do [X] we’re not going to stop you, so you can always force to override this” rather than in the mathematical “of course, [corollary] follows” tone, but I can see how it can be read differently.

              1. 1

                And it looks like the author changed “obviously” to “of course” now :)

                1. 1

                  Having any statement like that is useless. “Of course” would make as much sense if Mercurial forbade forcing.

                  It’s hard to stick just to the facts because interesting documentation often feels prosaic, though simply stating the way of things leads to less misunderstanding and head-scratching like “why is this of course?”

              2. 1

                That seems like a deep read with a strong reaction into one word, I think it probably says more about you than the author.

                1. 1

                  I think you are being very dismissive.

                  “Obvious”, “obviously”, and “clearly” are all problematic when writing or speaking.

                  Best case scenario:

                  Someone shares the same background as you do and it is obvious to them. In which case, you’ve gained nothing from the use of the word.

                  Likely scenario:

                  Someone doesn’t share the same background as you and it isn’t clear. For example, in this article, it is not all clear to me why you would design a system that would allow you to violate a state machine. At best here, the author did a poor job of explaining. “Obviously” here is standing in for a poor job of explaining a feature and its tradeoffs.

                  Worst case scenario:

                  Someone who is new to whatever the particular area is ends up feeling frustrated and gives up because they think it really should be obvious. If your goal as a writer is to teach people, you want to avoid this.

                  Anytime I find myself reaching for “obvious” as a term I stop and think, “why do I think that is obvious” and then explain it, because, invariably it is never obvious to all the members of the audience I am trying to reach.

                  1. 1

                    I think your critique of the word as a poor way to explain something is good and I think I agree with and I would have upvoted you if you just tried to offer a gentle suggestion on how to communicate better. I think it’s too far to say it’s “insulting” though. Someone is just trying to explain something and they used one word you have a problem with and now it’s insulting. Just because it triggered doesn’t don’t mean the author was anything other than just not realizing they used a word that didn’t help their explanation.

                    1. 3

                      I read what I wrote previously and it was overly short, poorly written and assumed too much about the audience. I was committing the same sin that I was complaining about in a different fashion.

                      1. 2

                        Thank you for being humble and thoughtful, I wish more internet discussions could be like this.