mercurial mq Re: RFR 8010325 : Remove hash32() method and hash32 int field from java.lang.String (original) (raw)

Paul Sandoz paul.sandoz at oracle.com
Mon Jun 17 09🔞57 UTC 2013

On Jun 14, 2013, at 10:36 PM, Martin Buchholz <martinrb at google.com> wrote:

On Thu, Jun 13, 2013 at 12:46 PM, Brent Christian <_ _brent.christian at oracle.com> wrote:

On 6/12/13 7:55 PM, David Holmes wrote:

Something of an aside but ...

On 13/06/2013 3:45 AM, Martin Buchholz wrote:

Hi Brent,

Thanks for doing this. Your webrev does not include mercurial changeset information, which I think is supported by recent webrevs.

Given the changeset has to be created after the review is complete most/many people will not have a changeset prepared at review time. That's it exactly. If at all possible, I don't commit until the code has completed code review. I tell webrev to do its thing based on modified files, rather than outgoing changesets. Hmmm.... I've been using mq for so long it's hard for me to imagine working without it. It allows others to review the mercurial changeset metadata, which is also the best summary to decide whether to review further.

+1

mq is the best way i have found to keep multiple patches in flight either in the same queue or using multiple queues, and avoid those annoying merge commits.

I wish there were better tooling support in IDEs for it.

Paul.

More information about the core-libs-dev mailing list