CODEWITHSUNDEEP
mercurial
Gili
Gili

Reputation: 90023

What is the expected workflow without pull requests?

I'm a big fan of Mercurial for my open-source projects, but I've never had the opportunity to use it at work.

I'm familiar with how Github pull requests work. What is the expected workflow in the Mercurial world for collaboration, assuming that pull requests don't exist (we don't use BitBucket or Gitlab)?

Say I have a public open-source repository, or a private work repository. How does someone propose non-trivial changes consisting of multiple commits? What options do we have for collaborating?

In the case of an open-source repository, I have to support both trusted and untrusted contribution requests. In the case of a work repository, I trust the contributor but the corporation mandate internal reviews for all contributions. Either way, it sounds as if we need a mechanism to notify authors of available contributions, some mechanism to discussion the contribution, and some mechanism to transfer changesets from the contributor to the official repository (given that the contributor might not have permission to push into the central repository but the central repository might have permission to pull from them).

Does code review software essentially handle everything I've mentioned above? Are pull requests really the only way to go?

Upvotes: 1

Views: 208

Answers (2)

Marcos Zolnowski
Marcos Zolnowski

Reputation: 2807

What is the expected workflow without pull requests?

Push directly to the repository.

Does code review software essentially handle everything I've mentioned above?

Yes, you should try Phabricator. See for yourself if they use pull-requests (cross repositories push).

Are pull requests really the only way to go?

No, but pull-requests fit well with most collaboration workflows. There are many ways. Pull requests favor pre-commit code-reviews, but you can also have a post-commit workflow.

If you are not using any code-review tool, only Mercurial and e-mails, you could do this:

  • For trusted contributors, you can set a fresh branch (and/or repository) to receive commits, do post-commit code-review. If they pass review, merge with the default branch.
  • For untrusted contributors, you can set a contributor repository to receive commits, do post-commit code-review. If they pass review, push it to the official repository, then merge with the default branch. Notify the review results using contributors e-mail (from the authors commit username).

If you find that only pull-requests fits your workflow or your tools, then the answer is: Yes.

Upvotes: 1

Lazy Badger
Lazy Badger

Reputation: 97282

Public forks

  • Ordinary and simple hg pull (each pull from fork will create at least anonymous branch, if not named)
  • MQ with MQ-Collab extension

Private forks

  • hg bundle + hg unbundle
  • hg export + hg import

Any media and any type of works

  • Exchange by shelves or queues

Upvotes: 0

Related Questions