About an IRC discussion on using pull requests for hg development

Idan Kamara idankk86 at gmail.com
Mon May 7 11:53:04 CDT 2012


On Mon, May 7, 2012 at 7:33 PM, Patrick Mézard <patrick at mezard.eu> wrote:

> Hello,
>
> Natosha wrote a wiki page about an IRC discussion which might be of
> interest for the coming sprint (and by the way, there should be more of
> those :-):
>
>  http://mercurial.selenic.com/wiki/ImprovingCollaboration


Another related discussion: http://markmail.org/message/qvkcuh5vnpyobb5n


>
>
>
>
> See below for my version.
>
> TL;DR:
> - Make history editing easier and safer (include histedit?)
> - Vague thoughts about supporting bitbucket-like pull requests while
> preserving an email-based review workflow.
>
>
> == 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)
>
> 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.
>
> 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.
>
>
> == 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.
> - 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.
>
> 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.
>
> --
> Patrick Mézard
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120507/fcd3dfcf/attachment.html>


More information about the Mercurial-devel mailing list