About an IRC discussion on using pull requests for hg development

Martin Geisler mg at aragost.com
Tue May 8 04:37:54 CDT 2012


Patrick Mézard <patrick at mezard.eu> writes:

> == What caught my attention (blame me if I misunderstood)
>
> 1- Patchbomb is hard (Tak)
> 2- Bitbucket/X pull requests are easier and more natural for submitters (Tak)
> 3- Tracking what is being reviewed and what is not is difficult (marmoute)
> 4- Submitters should not have to use mq or history rewriting tools
> (mg, maybe Tak, others)

My problem with this is that you cannot expect people to do it right the
first time, especially not new contributors. So we tell them "nice
patch, but this, this, and this is wrong". Now what? ContributingChanges
only says that people "might" find mq and record useful here.

The page doesn't say: Contributing to Mercurial absolutely requires you
to use mq or a similar history editing extension. We're sorry that the
core commands in our own version control system wont be enough to let
you contribute back to it. Oh, and forget about 'hg push', you need to
use email too. Have a good day!

I know it's not quite that bad, but still... :)

> If I cannot relate with [1] and [2], I can accept them at face value.
> If people are more comfortable with these tools, they could be
> supported in mercurial development workflow. [3] is not obvious if you
> follow closely the mailing list but for newcomers I suppose it is
> difficult to see what is being done.
>
>
> == History rewriting tools
>
> I disagree with [4]. Solving [4] suggests preserving all history until
> the submission converges to an acceptable state, at which point it is
> merged. After talking with mg, it seems to revolve around two notions:
>
> A- History immutability is strongly advertized as a Mercurial feature.
> B- History rewriting tools are not available by default.
>
> There seems to be a consensus that [B] comes from [A]. Both look
> unrelated to me: I can rewrite changesets locally while having
> immutable history on the reference repository which is what matters in
> practice. [B] is there to help people not shooting themselves in the
> foot when discovering Mercurial, which is good.

You're technically right that [A] and [B] are unrelated: Git has a model
that is just as immutable as Mercurial, but they have many rewriting
tools.

However, until 'hg commit --amend', we've delegated history editing to
extensions and this reinforces [A] and [B]. It would be cool to have a
push for more safe history rewring tools in core.

> The remaining argument in favour of [4] is history rewriting tools are
> hard or dangerous to use. Then I prefer making them easier and safer
> than accepting unpolished revisions. Maybe we should consider again
> improving and including histedit, or another similar extension, so we
> have a less baroque default tool than mq for history rewriting.

I think including histedit is a good idea: judging from the popularity
of 'git rebase -i', people like the interface.

> == Pull requests
>
> Here are random thoughts about improvements for [1], [2] and [3].
>
> Constraints:

> - Everything should happen on mercurial-devel mailing list first, and
> possibly be mirrored.

Just for the record: I prefer the mailinglist over notifications on
Bitbucket. it's silly and annoying that they've implemented yet another
messaging system.

> - I assume pulling/merging is acceptable if it is easy to check what
> is pulled is what was reviewed
> - It should not be expensive to implement/deploy or it will never
> happen, again.
>
> Mercurial has an official mirror on X, where X == bitbucket for now.
> People can fork and make pull requests. An agent listens to pull
> requests (smtp hook, HTTP polling, whatever works). When triggered, it
> pulls and patchbomb mercurial-devel, with an introduction email
> linking to the pull request. The agent would listen to mercurial-devel
> as well and when the introduction message is seen, post a notification
> in the pull request on X so the submitter knows about the review
> process on mercurial-devel. That is a minimal setup.

Sounds good! Maybe we can get Bitbucket to extend whatever needs to be
extended to make this work smoothly.

> It is desirable to mirror the reviews into the pull request on X, but
> not easy to achieve without proper APIs.
>
> When a pull request is accepted, it is pulled via X interface and merged.

The other way is already automated in Bitbucket: a pull request is
marked as accepted when Bitbucket sees that the changesets in question
have been merged. So you don't need to go back to the web interface and
click "accept" after pushing the merge to BB.

-- 
Martin Geisler

aragost Trifork
Commercial Mercurial support
http://aragost.com/mercurial/


More information about the Mercurial-devel mailing list