A week ago, I was at LFNW and as I was talking with Larry Hastings after his talk, he said (paraphrased):

There's something in Git that makes the Pull Request workflow possible that isn't there in Mercurial. That's why Pull Requests on BitBucket are not great.

(For context, we were discussing the fact that Python is moving from Mercurial to Git because of the PR workflow, as opposed to the file-bug-then-attach-patch workflow.)

What is he talking about here? Neither of us could come up with the name of whatever it was. I've searched the web with no luck.


1 Answer 1


You should probably read through the PEP yourself. Either Larry Hastings is confused or something was lost in communication. The reasons for moving to git and github over mercurial are not technical, but social. A pull request workflow is perfectly well supported with mercurial, but github is the one with the much wider userbase over bitbucket and slightly better code review features.

  • The "distributed" nature of Git has nothing to do with it? May 1, 2016 at 1:55
  • 12
    Mercurial is just as distributed. Mercurial and git differ in implementation details and minor features, but on the main points they are essentially identical. May 1, 2016 at 2:36
  • 10
    @RobertHarvey Pull requests don't have any real "implementation" in the actual versioning system. They're merely a "I want to merge this" note outside the system.
    – Mario
    May 1, 2016 at 6:15
  • 1
    We must be doing it wrong then - our HG pullrequests are polluted with ALL diff from 'Source' between 'Current Source' and 'PR'. With git repos, we only see changes made in 'PR', making reviews humanly possible. Our (wanting) understanding of this difference is that it's related to the immutable nature of HG branches
    – Julian
    Nov 24, 2017 at 8:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.