Fwd: mercurial: on your commits about hash collisions

Alex says his emails are not getting through to the mailing list. Any idea why? Maybe Augie knows? -- Forwarded message - From: Александр Литягин Date: Sat, Apr 30, 2022, 06:59 Subject: mercurial: on your commits about hash collisions To: Hallow Martin! You`ve commited into me

Re: Will work on adding allowing merge tools to partially resolve conflicts

On Fri, Dec 3, 2021 at 7:23 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > On 11/30/21 12:29 AM, Martin von Zweigbergk via Mercurial-devel wrote: > > I will work on teaching the merge machinery to call external merge > > tools to let them partially resol

Will work on adding allowing merge tools to partially resolve conflicts

Hi, Just a heads up that I will work on teaching the merge machinery to call external merge tools to let them partially resolve a merge. That will require a different protocol for interacting with the merge tool. We're going to pass the merge tool 3 inputs and expect 3 possibly modified outputs, i

6.0 Sprint?

Hi, We haven't had a sprint in a long time. Do we want one before the end of the year? Is anyone willing to organize it? I think Anton said he might know someone who would be interested. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org

Re: Evolve mini-sprint October 8th

On Wed, Sep 29, 2021 at 1:18 AM Raphaël Gomès wrote: > On 9/28/21 11:15 PM, Martin von Zweigbergk via Mercurial-devel wrote: > > We haven't had a regular (Mercurial-scoped) sprint in a long time. What do > you think about promoting this Evolve sprint to a full Mercurial sprin

Re: Evolve mini-sprint October 8th

We haven't had a regular (Mercurial-scoped) sprint in a long time. What do you think about promoting this Evolve sprint to a full Mercurial sprint? On Tue, Sep 28, 2021 at 1:46 PM Anton Shestakov wrote: > Hello everyone, > > Keeping the tradition of monthly mini-sprints related to all things > M

Re: Which parts of Evolve can be upstreamed?

On Mon, Feb 8, 2021 at 11:28 PM Pierre-Yves David wrote: > > The short answer is: > > They are comment in multiple source files about their status and the > part that can be uptreamed. > > > For a longer answer I need to double check my notes. > On a general basis : > - The user facing command is

Which parts of Evolve can be upstreamed?

Hi, We have talked about upstreaming the Evolve extension for years and some of it has been upstreamed, but most of it remains. I think most of us agree that it would be good to have it upstreamed at some point. Are there some uncontroversial parts that I can start moving upstream? The obslog and

Re: How to use the templater without color (even when ui has color)

That's not a solution I would have thought of. Thanks! I've sent a fix for `hg split` in https://phab.mercurial-scm.org/D9322. I'll work on one for histedit now. Hopefully testing it is not too annoying. On Sat, Nov 14, 2020 at 1:19 AM Yuya Nishihara wrote: > On Fri, 13 Nov 2020 09:20:24 -0800,

How to use the templater without color (even when ui has color)

Hi Yuya, I recently added support for some templated output in `hg split` ( https://phab.mercurial-scm.org/D9255). I didn't realize when I wrote the patch that it was producing the templated output for use in a commit message template. The effect was that color codes ended up in the commit message

Re: Tentative sprint schedule

2 are > largely "burn it with fire" at this point...and I don't think I feel > strongly on any of the other topics. > > Other than that, LGTM > > On Nov 2, 2020, at 18:18, Martin von Zweigbergk via Mercurial-devel < > mercurial-devel@mercurial-scm.org&g

Re: Formatting of output from evolve

For the record, Pierre-Yves replied on IRC that he's for the change. I don't think there was any indication there if we should use the same format by default or not. I decided against it in https://foss.heptapod.net/mercurial/evolve/-/merge_requests/277 (see the commit messages there for my reasoni

Tentative sprint schedule

Based on the topics people have indicated their interest in and the time zones, I've put down a tentative schedule in https://docs.google.com/spreadsheets/d/1-PhQvYRmUk2LRrpKZg32fktAsfBRN93WC1GKCnDK7YY/edit?usp=sharing . I don't know which topics will need more than 30 minutes except for my own De

Formatting of output from evolve

Hi, I recently made an effort to standardize the formatting of one-line commit summaries in Mercurial ( e.g. https://phab.mercurial-scm.org/D9251, https://phab.mercurial-scm.org/D9252, https://phab.mercurial-scm.org/D9262). It would be nice if evolve respected the same configuration. I can send p

Re: Please sign up for the (virtual) sprint if you're interested

On Mon, Oct 19, 2020 at 9:21 PM Martin von Zweigbergk wrote: > The first day that everyone seems to be available is Nov 5 (Thursday). I > propose that we do at least a first session where we try to get everyone to > join a conference call. We could use that for at least meet-and-greet and > maybe

Re: [PATCH 1 of 2] revset: rename diff(pattern) to diffcontains(pattern)

Pulkit, do you think you can queue this series? I don't have queuing-from-email set up. On Wed, Oct 21, 2020 at 3:59 AM Yuya Nishihara wrote: > On Sat, 17 Oct 2020 13:56:03 +0900, Yuya Nishihara wrote: > > # HG changeset patch > > # User Yuya Nishihara > > # Date 1602907204 -32400 > > # Sa

Re: Please sign up for the (virtual) sprint if you're interested

The first day that everyone seems to be available is Nov 5 (Thursday). I propose that we do at least a first session where we try to get everyone to join a conference call. We could use that for at least meet-and-greet and maybe coming up with a schedule for the rest of the sprint. We have various

Re: Default behavior of `hg absorb` with respect to empty changesets

On Mon, Oct 12, 2020 at 5:39 AM Yuya Nishihara wrote: > On Sun, 11 Oct 2020 05:25:01 +0200, Manuel Jacob wrote: > > In 1ca0047fd7e1, I changed the default behavior of absorb to preserve > > empty changesets that were already empty. Changesets that become empty > > continue to be dropped by defaul

Please sign up for the (virtual) sprint if you're interested

The next sprint will be virtual and will probably consist of mostly separate meetings spread out over the week of Nov 2 (if that week seems to work for people). Please mark your availability on https://www.mercurial-scm.org/wiki/5.6Sprint if you would like to participate. Also feel free to add topi

Re: ShareSafePlan

> <mailto:pierre-yves.da...@ens-lyon.org>> wrote: > > >> > > >> > > >> > > >> On 9/15/20 7:35 PM, Martin von Zweigbergk via Mercurial-devel > wrote: > > >> > I read https://www.mercurial-s

Re: Virtual sprint? Ideas?

Done. Please add your availability there if you want to join. On Sun, Sep 27, 2020 at 12:56 PM Augie Fackler wrote: > Sure. It’s better in general to sprint after a release because then we’re > not all focussed on getting a stable release out the door and can have > slightly more experimental di

Re: Virtual sprint? Ideas?

Pierre-Yves said on chat that we usually try to do the sprint right after a release. That would mean the week of November 2. Sounds good? On Wed, Sep 23, 2020 at 9:04 PM Martin von Zweigbergk wrote: > I created a wiki page for the sprint: > https://www.mercurial-scm.org/wiki/5.6Sprint. It's just

Re: Virtual sprint? Ideas?

I created a wiki page for the sprint: https://www.mercurial-scm.org/wiki/5.6Sprint. It's just my attempt to move the discussion forward. Please fill in your availability there if it seems like a good idea, or let me know what you think we should change (or make the edits yourself if they're uncontr

Re: May I delete merge driver?

Okay, I've dropped the "RFC: " prefix from that review :) But let's give others a chance to comment. On Fri, Sep 18, 2020 at 7:16 AM Augie Fackler wrote: > Honestly if it's untested in core that probably means nobody outside FB > ever figured out a way to use it. I'd go ahead and drop it. > > On

Re: May I delete merge driver?

Here's what that may look like: https://phab.mercurial-scm.org/D9041 On Thu, Sep 17, 2020 at 10:13 PM Martin von Zweigbergk < martinv...@google.com> wrote: > It doesn't seem like the merge driver code came with any tests or > documentation. I would therefore not be surprised if it's already broke

May I delete merge driver?

It doesn't seem like the merge driver code came with any tests or documentation. I would therefore not be surprised if it's already broken. I'd like to delete it instead of spending time trying to update it correctly while refactoring the merge code. Any objections?

Re: ShareSafePlan

gt; >> > >> > >> > >> On 9/15/20 7:35 PM, Martin von Zweigbergk via Mercurial-devel wrote: > >> > I read https://www.mercurial-scm.org/wiki/ShareSafePlan. It has > >> > examples of things that *should* be read from the source repo, but I &g

Re: ShareSafePlan

On Tue, Sep 15, 2020 at 12:34 PM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > > > On 9/15/20 7:35 PM, Martin von Zweigbergk via Mercurial-devel wrote: > > I read https://www.mercurial-scm.org/wiki/ShareSafePlan. It has > > examples of things that *shou

ShareSafePlan

I read https://www.mercurial-scm.org/wiki/ShareSafePlan. It has examples of things that *should* be read from the source repo, but I don't see examples of things that should *not* be read from the source repo. Can you give examples of things that would break if a share repo read its configs as usu

Re: [PATCH 2 of 4] rebase: add config that causes empty changesets to be created

On Thu, Jul 9, 2020 at 2:36 PM Manuel Jacob wrote: > On 2020-07-09 18:48, Martin von Zweigbergk wrote: > > On Thu, Jul 9, 2020 at 12:35 AM Manuel Jacob wrote: > > > >> On 2020-07-08 01:29, Martin von Zweigbergk via Mercurial-devel wrote: > >> > Other reasons

Re: [PATCH 2 of 4] rebase: add config that causes empty changesets to be created

On Thu, Jul 9, 2020 at 12:35 AM Manuel Jacob wrote: > On 2020-07-08 01:29, Martin von Zweigbergk via Mercurial-devel wrote: > > Other reasons to always create the empty successor (in addition to just > > having useful information in `hg obslog`): > > > > * orphans

Re: [PATCH 2 of 4] rebase: add config that causes empty changesets to be created

Other reasons to always create the empty successor (in addition to just having useful information in `hg obslog`): * orphans on the predecessor would be evolved onto the successor instead of being evolved onto the predecessor's parent. `hg evolve` could be taught to evolve not evolve the orphan on

Re: Virtual sprint? Ideas?

Sounds like a good idea to me! When do we want to do the next sprint? I think it would make sense to have one sooner than the usual ~October time frame since we missed the spring one. That should probably be possible since we won't need to plan travel. On Mon, Jun 22, 2020 at 5:26 AM Raphaël Gomè

Re: How should we include extra modules in a pyoxidized Mercurial?

Thanks! The library we wanted to install this time was `xattr`, which has this line: https://github.com/xattr/xattr/blob/master/xattr/lib_build.py#L5. How do you recommend working around that? Do we simply need to install it in the file system instead of bundling it in the binary? On Wed, Jun 17

Re: planned work: minimal/partial Rust executable utility

That sounds like what Greg has advocated for some time, and also what FB has done internally. I think Greg's plan was to incrementally add more code to what's currently a very thin wrapper created by PyOxidizer. Then there would be no need for a separate binary. I think that sounds like a good ide

Re: Getting graphshorten out of experimental?

I know there are some issues where it draws commits stacked on each other where there is actually no parent/child relationship. However, graph output is clearly not something people should write scripts on top of, so I don't see any harm in letting it graduate even if we change the output later to

Re: Moving patches traffic to a another list?

On Thu, Mar 26, 2020 at 4:03 PM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > > > On 3/26/20 8:56 PM, Martin von Zweigbergk via Mercurial-devel wrote: > > And we add all existing subscribers of mercurial-devel@ to the new one, > > I hope? > > C

Re: Moving patches traffic to a another list?

And we add all existing subscribers of mercurial-devel@ to the new one, I hope? On Thu, Mar 26, 2020 at 11:13 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > Okay, if I read this thread correctly, nobody is strongly against it and > some people agree it could help. I addition, I w

Re: Moving patches traffic to a another list?

:09, Pierre-Yves David < > pierre-yves.da...@ens-lyon.org> wrote: > >>> > >>> > >>> > >>> On 3/20/20 4:42 PM, Martin von Zweigbergk via Mercurial-devel wrote: > >>>> On Fri, Mar 20, 2020 at 8:39 AM Pierre-Yves David < &

Re: Moving patches traffic to a another list?

On Fri, Mar 20, 2020 at 8:39 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > > > On 3/20/20 4:19 PM, Yuya Nishihara wrote: > > > unless we're willing to use the mailing list (or plain emails) > extensively. > > That's what I am trying to achieve here :-), more direct communication

Re: Moving patches traffic to a another list?

I agree with Yuya. I read phabricator threads if the email subject interests me or if I'm added to the thread for some reason. Otherwise I mostly ignore the threads there. On Fri, Mar 20, 2020 at 8:36 AM Yuya Nishihara wrote: > On Fri, 20 Mar 2020 15:51:12 +0100, Pierre-Yves David wrote: > > The

Re: [PATCH 1 of 7 RESEND] rust-cpython: remove useless wrappers from PyLeaked, just move by map()

I think I've already queued this series. Sorry that I forgot to say so. On Fri, Jan 31, 2020 at 11:27 AM Augie Fackler wrote: > On Wed, Jan 29, 2020 at 10:56:51AM +0100, Raphaël Gomès wrote: > > I had already reviewed these patches last time, so +1 for me, especially > now > > that the whole ref

Re: [PATCH 3 of 5 STABLE] py3: send bytes from Rust-created warning patterns

On Thu, Dec 12, 2019 at 9:14 AM Raphaël Gomès wrote: > # HG changeset patch > # User Raphaël Gomès > # Date 1574095079 -3600 > # Mon Nov 18 17:37:59 2019 +0100 > # Branch stable > # Node ID 2f084275a6435092058eaf9cb1a46cc6d7b0821a > # Parent 697e5119ce5d2ae8c7ef048a8a18e2b15c7af17a > py3:

Re: Making Rust respect worker count in config

Seems fine to do that every time we read configs in Python. It won't always be correct if there are multiple values for it in different config files (e.g. repo-specific vs user's config). Probably good enough. On Thu, Nov 7, 2019, 07:54 Raphaël Gomès wrote: > I'd like to make Rust respect to max

Re: D7181: py3: make chistedit render

Feel free to do that in flight. Otherwise I'll do it later today. It won't matter in practice. We should of course have a separate method explicitly for creating a line instead. But that's not for stable. On Fri, Nov 1, 2019, 06:42 yuja (Yuya Nishihara) < phabrica...@mercurial-scm.org> wrote: >

Re: [PATCH 3 of 6] packaging: upgrade Debian packaging to build with Python 3

Queued patches 3-6 for stable. Thanks a lot! It would have taken me a long time to figure out how to do this, and it would have been done in a worse way. On Mon, Oct 21, 2019 at 8:07 PM Yuya Nishihara wrote: > On Mon, 21 Oct 2019 20:05:41 -0700, Martin von Zweigbergk wrote: > > Yuya, are you oka

Re: [PATCH 3 of 6] packaging: upgrade Debian packaging to build with Python 3

el < > mercurial-devel@mercurial-scm.org> wrote: > >> >> On 21/10/19 21:52, Augie Fackler wrote: >> > On Mon, Oct 21, 2019 at 09:30:27AM -0700, Martin von Zweigbergk via >> Mercurial-devel wrote: >> >> On Mon, Oct 21, 2019 at 9:21 AM Gregory

Re: [PATCH 3 of 6] packaging: upgrade Debian packaging to build with Python 3

, Oct 21, 2019 at 09:30:27AM -0700, Martin von Zweigbergk via > Mercurial-devel wrote: > >> On Mon, Oct 21, 2019 at 9:21 AM Gregory Szorc > >> wrote: > >> > >>> On Mon, Oct 21, 2019 at 6:57 AM Yuya Nishihara wrote: > >>> > >>>> On

Re: [PATCH 3 of 6] packaging: upgrade Debian packaging to build with Python 3

On Mon, Oct 21, 2019 at 9:53 AM Yuya Nishihara wrote: > On Mon, 21 Oct 2019 09:01:51 -0700, Gregory Szorc wrote: > > On Mon, Oct 21, 2019 at 6:57 AM Yuya Nishihara wrote: > > > On Mon, 21 Oct 2019 12:00:55 +0200, Denis Laxalde wrote: > > > > # HG changeset patch > > > > # User Denis Laxalde > >

Re: [PATCH 3 of 6] packaging: upgrade Debian packaging to build with Python 3

On Mon, Oct 21, 2019 at 9:21 AM Gregory Szorc wrote: > On Mon, Oct 21, 2019 at 6:57 AM Yuya Nishihara wrote: > >> On Mon, 21 Oct 2019 12:00:55 +0200, Denis Laxalde wrote: >> > # HG changeset patch >> > # User Denis Laxalde >> > # Date 1571648394 -7200 >> > # Mon Oct 21 10:59:54 2019 +0200

Re: [PATCH 3 of 6] packaging: upgrade Debian packaging to build with Python 3

On Mon, Oct 21, 2019, 08:32 Denis Laxalde wrote: > Martin von Zweigbergk a écrit : > > On Mon, Oct 21, 2019, 06:57 Yuya Nishihara wrote: > > > > > On Mon, 21 Oct 2019 12:00:55 +0200, Denis Laxalde wrote: > > > > # HG changeset patch > > > > # User Denis Laxalde > > > > # Date 1571648394 -7200 >

Re: [PATCH 3 of 6] packaging: upgrade Debian packaging to build with Python 3

On Mon, Oct 21, 2019, 06:57 Yuya Nishihara wrote: > On Mon, 21 Oct 2019 12:00:55 +0200, Denis Laxalde wrote: > > # HG changeset patch > > # User Denis Laxalde > > # Date 1571648394 -7200 > > # Mon Oct 21 10:59:54 2019 +0200 > > # Node ID 09f95d7a20c6d2e0bf6218e2a5bc9cd2b803c8ec > > # Parent

Re: [PATCH 4 of 4] py3: adjust expected traceback in test-hook.t

Queuing this, thanks. On Fri, Oct 18, 2019 at 8:01 AM Denis Laxalde wrote: > # HG changeset patch > # User Denis Laxalde > # Date 1571410286 -7200 > # Fri Oct 18 16:51:26 2019 +0200 > # Node ID 1c619a074a1ef5905d5262ca9d669e4c12e73fc2 > # Parent a2e16cda007faf54c2674db8de0eaf30faa15206 >

Re: [PATCH 1 of 6 V3] rust-cpython: put leaked reference in PyLeakedRef

Queuing this, thanks. On Thu, Oct 17, 2019 at 6:14 AM Yuya Nishihara wrote: > # HG changeset patch > # User Yuya Nishihara > # Date 1568552779 -32400 > # Sun Sep 15 22:06:19 2019 +0900 > # Node ID 30ad653deb7fbe2196f3d2d9d97f9f650c8b7952 > # Parent 2c70dd03b74395fbec276a2e2d1d3b8347268a5d

Re: [PATCH 1 of 5] rust-cpython: put leaked reference in PyLeakedRef

Heh, I have no idea which one I queued. I know you said you forgot --flag V2, so I assumed the two series I saw on patchwork were the same. On Mon, Oct 14, 2019, 07:17 Yuya Nishihara wrote: > On Mon, 14 Oct 2019 10:10:34 +0200, Raphaël Gomès wrote: > > I think Georges reviewed the other patch se

Re: [PATCH 1 of 2] patchcopies: give up any optimization based on `introrev`

I've updated the queued version: 1. ran contrib/grey.py on it (I also did that on one of your recent perf patches) 2. s/patchcopies/pathcopies/ in the commit message On Sun, Oct 13, 2019 at 9:10 PM Yuya Nishihara wrote: > On Sun, 13 Oct 2019 23:02:25 +0200, Pierre-Yves David wrote: > > On 10/13

Re: [PATCH 1 of 5] rust-cpython: put leaked reference in PyLeakedRef

On Sun, Oct 13, 2019 at 8:52 PM Yuya Nishihara wrote: > On Sun, 13 Oct 2019 07:46:14 -0700, Martin von Zweigbergk wrote: > > On Sat, Oct 12, 2019, 01:06 Yuya Nishihara wrote: > > > # HG changeset patch > > > # User Yuya Nishihara > > > # Date 1568552779 -32400 > > > # Sun Sep 15 22:06:19 2

Re: [PATCH 1 of 5] rust-cpython: put leaked reference in PyLeakedRef

On Sat, Oct 12, 2019, 01:06 Yuya Nishihara wrote: > # HG changeset patch > # User Yuya Nishihara > # Date 1568552779 -32400 > # Sun Sep 15 22:06:19 2019 +0900 > # Node ID 458c6598a13caee640294d88af4e93783fc36476 > # Parent ce20b870041fc4d6ba6989acbb9373797ce9b3d6 > rust-cpython: put leaked

Re: [PATCH 1 of 3] singlehead: fix a small typo in a test comment

On Wed, Sep 25, 2019 at 4:11 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > # HG changeset patch > # User Pierre-Yves David > # Date 1569407734 -7200 > # Wed Sep 25 12:35:34 2019 +0200 > # Node ID 8a8b17fc108c6859633ea810935a123cb7937530 > # Parent 39cab871e8801489fcb602252

Re: [PATCH] archive: add XZ support if built with Python 3

Yes, it's already accepted. I meant that I fixed those things in flight. So no follow-up needed. On Wed, Sep 18, 2019, 00:22 David Demelier wrote: > Le 17/09/2019 à 19:18, Martin von Zweigbergk a écrit : > > > > > > On Tue, Sep 17, 2019 at 7:16 AM Augie Fackler > > wrot

Re: [PATCH] archive: add XZ support if built with Python 3

On Tue, Sep 17, 2019 at 7:16 AM Augie Fackler wrote: > > > > On Sep 17, 2019, at 06:48, David Demelier wrote: > > > > # HG changeset patch > > # User David Demelier > > # Date 1568717251 0 > > # Tue Sep 17 10:47:31 2019 + > > # Node ID c0398aef7f0977b5f076b15638762773dde7d5b6 > > # Par

Re: [PATCH 5 of 5] changegroup: move message about added changes to transaction summary

On Mon, Sep 9, 2019 at 10:27 PM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > On 9/10/19 6:01 AM, Martin von Zweigbergk wrote: > > > > > > On Sun, Sep 8, 2019 at 1:09 AM Pierre-Yves David > > mailto:pierre-yves.da...@ens-lyon.org>> > > > wrote: > > > > # HG changeset patch > >

Re: [PATCH 5 of 5] changegroup: move message about added changes to transaction summary

On Sun, Sep 8, 2019 at 1:09 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > # HG changeset patch > # User Pierre-Yves David > # Date 1567928573 -7200 > # Sun Sep 08 09:42:53 2019 +0200 > # Node ID 275367f9cadd11d65128051d920414f4b76f5de6 > # Parent 426a83641e1b9a94775bd2c3db

Re: [PATCH 1 of 2] rust-dirstate: add helper to iterate ancestor paths

On Sun, Jun 30, 2019, 04:17 Yuya Nishihara wrote: > # HG changeset patch > # User Yuya Nishihara > # Date 1561887163 -32400 > # Sun Jun 30 18:32:43 2019 +0900 > # Node ID 72ab74c704053b2212b874a902574fedadad4252 > # Parent 904e0da2e195d2a29977ceccdd25480233c34d7a > rust-dirstate: add helpe

Re: [PATCH evolve-ext v2] py3: broad pass for python3 compatibility

On Thu, Jul 4, 2019, 16:59 Ludovic Chabant wrote: > > > > > Should opts[x], opts.get(x), etc really use bytes? They usually get > passed as **opts, which means their keys are str, I think. > > > > Sounds OK to me -- there's probably a whole bunch of places that might > need to be excluded. It mig

Re: D6602: copies: inline _chainandfilter() to prepare for next patch

Wow, Phabricator decides to send the email almost two full days after the review was created. Anyone knows what's going on? On Thu, Jul 4, 2019, 09:13 martinvonz (Martin von Zweigbergk) < phabrica...@mercurial-scm.org> wrote: > martinvonz created this revision. > Herald added a subscriber: mercur

Re: [PATCH evolve-ext v2] py3: broad pass for python3 compatibility

On Sun, Jun 30, 2019 at 10:42 PM Ludovic Chabant wrote: > # HG changeset patch > # User Ludovic Chabant > # Date 1561959530 0 > # Mon Jul 01 05:38:50 2019 + > # Branch stable > # Node ID 89e3ab4dcbc56ee72ce1d4d17527337e01d99467 > # Parent 90daf413dfc7a7e4762e6445f05c52b123c6188f > py3:

Re: [PATCH 4 of 4 accept-scripts] land: fix logic so that reviewers work as intended

Sorry that I forgot to reply earlier, but feel free to push this series (as far as I'm concerned anyway -- up to you if want Kevin's approval too). On Tue, Jun 11, 2019 at 10:10 PM Augie Fackler wrote: > These resolve the mysterious "why aren't things landing" situation we've > currently got. I

Re: [PATCH] discovery: be more conservative when adjusting the sample size

On Wed, Jun 5, 2019 at 8:16 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > > > On 6/5/19 3:21 PM, Martin von Zweigbergk wrote: > > > > > > On Wed, Jun 5, 2019, 03:36 Pierre-Yves David > > mailto:pierre-yves.da...@ens-lyon.org>> > > > wrote: > > > > # HG changeset patch > >

Re: [PATCH] discovery: be more conservative when adjusting the sample size

On Wed, Jun 5, 2019, 03:36 Pierre-Yves David wrote: > # HG changeset patch > # User Pierre-Yves David > # Date 1559726605 -7200 > # Wed Jun 05 11:23:25 2019 +0200 > # Node ID 2c67430451fafcdd68770436c520e2d008428986 > # Parent 12793787439538411013edffe0f9b98762d38a37 > # EXP-Topic discover

Re: [PATCH 2 of 2] perf: add an option to profile the benchmark section

On Wed, May 22, 2019, 07:49 Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > # HG changeset patch > # User Pierre-Yves David > # Date 1558445208 -7200 > # Tue May 21 15:26:48 2019 +0200 > # Node ID b5c316b4248f3add425313ac0f443c706b79 > # Parent 8553423d79608bd5d144456448509

Re: [PATCH] discovery: slowly increase sampling size

On Tue, May 21, 2019 at 1:24 PM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > > > On 5/21/19 10:00 PM, Martin von Zweigbergk wrote: > > > > > > On Tue, May 21, 2019 at 11:10 AM Martin von Zweigbergk > > mailto:martinv...@google.com>> wrote: > > > > > > > > On Tue, May 21, 2019 a

Re: [PATCH] discovery: slowly increase sampling size

On Tue, May 21, 2019 at 11:10 AM Martin von Zweigbergk < martinv...@google.com> wrote: > > > On Tue, May 21, 2019 at 10:09 AM Pierre-Yves David < > pierre-yves.da...@ens-lyon.org> wrote: > >> >> >> On 5/21/19 6:05 PM, Martin von Zweigbergk wrote: >> > >> > >> > On Tue, May 21, 2019 at 4:22 AM Pier

Re: [PATCH] discovery: slowly increase sampling size

On Tue, May 21, 2019 at 10:09 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > > > On 5/21/19 6:05 PM, Martin von Zweigbergk wrote: > > > > > > On Tue, May 21, 2019 at 4:22 AM Pierre-Yves David > > mailto:pierre-yves.da...@ens-lyon.org>> > > > wrote: > > > > # HG changeset patch

Re: [PATCH] discovery: slowly increase sampling size

On Tue, May 21, 2019 at 4:22 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > # HG changeset patch > # User Pierre-Yves David > # Date 1558436902 -7200 > # Tue May 21 13:08:22 2019 +0200 > # Node ID 123267b121ea268b3bc488c6dde68a8d93ee4f4c > # Parent 86f17fc31aa8a0c26c11db6a5

Re: Google Summer of Code '19: Add functionality to store an unresolved merge-state

is week. > I vote for approach 2. > > Thanks and regards, > Navaneeth > > > On Wed, May 15, 2019 at 11:58 PM Navaneeth Suresh < > navaneeths1...@gmail.com> wrote: > >> On Wed, 15 May, 2019, 10:26 PM Pulkit Goyal, <7895pul...@gmail.com> >> wrote:

Re: Is anyone using patchwork?

On Fri, May 17, 2019 at 12:11 PM Pulkit Goyal <7895pul...@gmail.com> wrote: > > > On Fri, May 17, 2019 at 9:53 PM Martin von Zweigbergk via Mercurial-devel < > mercurial-devel@mercurial-scm.org> wrote: > >> A few users still send patches by email. I use patchwo

Re: Is anyone using patchwork?

A few users still send patches by email. I use patchworks when I queue their patches. If you're okay with queuing patches from these (few) users, I'm okay with shutting down patchworks. Or maybe there's another way to get the patches without installing a mail client? On Fri, May 17, 2019 at 11:44

Re: [PATCH] log: flag topo-sorted set as such

On Wed, May 15, 2019 at 4:34 PM Yuya Nishihara wrote: > # HG changeset patch > # User Yuya Nishihara > # Date 1557962120 -32400 > # Thu May 16 08:15:20 2019 +0900 > # Node ID 77eb2f52d411836a9f7cadd7b3c7d095945cadcc > # Parent 52c3d16d4c62567e4858ddc8c082443a1f7a2f78 > log: flag topo-sorte

Re: Google Summer of Code '19: Add functionality to store an unresolved merge-state

*From: *Navaneeth Suresh *Date: *Wed, May 15, 2019 at 5:13 AM *To: *Pierre-Yves David *Cc: *mercurial-devel On Tue, May 14, 2019 at 5:51 PM Pierre-Yves David < > pierre-yves.da...@ens-lyon.org> wrote: > >> >> >> On 5/12/19 8:31 PM, Navaneeth Suresh wrote: >> > Hello everyone, >> > >> > I am Navan

Re: D6369: templatekw: get file_{adds, mods, dels} directly from context (issue4292)

*From: *yuja (Yuya Nishihara) *Date: *Sat, May 11, 2019, 20:17 *To: * yuja added a comment. > > > > This redefines the template keywords by getting the lists from the > > recently introduced context methods instead of getting them from > > status compared to p1. A mentioned before, t

Re: D6367: context: add modified(), added(), removed() to changectx too

*From: *yuja (Yuya Nishihara) *Date: *Sat, May 11, 2019, 20:12 *To: * yuja added a comment. > > > > +def modified(self): > > +modified = set(self.files()) > > +modified.difference_update(self.added()) > > +modified.difference_update(self.removed()) > > +

Re: Blackening redux (was: Re: Auto-formatting code with black - object now if you have a strong opinion)

*From: *Gregory Szorc *Date: *Wed, May 8, 2019, 19:32 *To: *Augie Fackler *Cc: *mercurial-devel@mercurial-scm.org, Matt Harbison On Wed, May 8, 2019 at 12:42 PM Augie Fackler wrote: > >> >> >> > On Dec 6, 2018, at 23:21, Matt Harbison wrote: >> > >> > On Wed, 05 Dec 2018 08:23:17 -0500, Yuya Ni

Re: Blackening redux (was: Re: Auto-formatting code with black - object now if you have a strong opinion)

*From: *Matt Harbison *Date: *Wed, May 8, 2019, 19:56 *To: *Augie Fackler, Martin von Zweigbergk *Cc: *Mercurial-devel, Gregory Szorc On Wed, 08 May 2019 17:13:30 -0400, Martin von Zweigbergk > wrote: > > > *From: *Augie Fackler > > *Date: *Wed, May 8, 2019 at 2:05 PM > > *To: *martinvonz > > *

Re: Blackening redux (was: Re: Auto-formatting code with black - object now if you have a strong opinion)

*From: *Augie Fackler *Date: *Wed, May 8, 2019 at 2:05 PM *To: *martinvonz *Cc: *Matt Harbison, Mercurial-devel, Gregory Szorc > > > On May 8, 2019, at 16:53, martinvonz wrote: > > > >> * one-tuples will get forced down to a single line, even if they > started on multiple lines > > > > I don't

Re: [PATCH] histedit: Show file names in multiple line format

On Sun, May 5, 2019 at 1:05 PM Feng Yu wrote: > Thanks for looking into this. > > Is there anything that I shall do from my end? > No, I don't think so. > > - Yu > > On Thu, May 2, 2019 at 7:21 PM Jordi Gutiérrez Hermoso > wrote: > >> On Thu, 2019-05-02 at 16:51 -0700, Martin von Zweigbergk w

Re: [PATCH 2 of 2] commit: add ability to print file status after each successful invocation

I feel like this feature goes against the idea of orthogonal commands and that it could easily be achieved with a hook. Is it a common enough request to have it in core? OTOH, it's a very simple feature, so I'm not too concerned with having it in core. *From: *Augie Fackler *Date: *Sat, May 4, 20

Re: [PATCH 3 of 3] updatecaches: also warm hgtagsfnodescache

I applied this this in flight: --- a/tests/test-server-view.t +++ b/tests/test-server-view.t @@ -51,6 +51,7 @@ Check same result using `experimental.ex $ ls -1 test/.hg/cache/ branch2-base%89c45d2fa07e branch2-served + hgtagsfnodes1 rbc-names-v1 rbc-revs-v1 tags2 On Fri, May

Re: [PATCH 3 of 3] updatecaches: also warm hgtagsfnodescache

On Thu, May 2, 2019 at 9:34 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > # HG changeset patch > # User Pierre-Yves David > # Date 1552268118 -3600 > # Mon Mar 11 02:35:18 2019 +0100 > # Node ID 8e2bc8ccf591f453d417fc1bd5c77a18510b954d > # Parent eac353183daaef0a503da8cd72

Re: [PATCH STABLE] parser: fix crash by parsing "()" in keyword argument position

On Fri, May 3, 2019 at 4:35 AM Yuya Nishihara wrote: > # HG changeset patch > # User Yuya Nishihara > # Date 1556881563 -32400 > # Fri May 03 20:06:03 2019 +0900 > # Branch stable > # Node ID caaf1fa0f73f56f8fcfd5408d7fa0dfaa8a2a510 > # Parent 724dae82c4bd935c19377c666bb5ef230aa32dd3 > par

Re: [PATCH] histedit: Show file names in multiple line format

I've queued these mostly bases on Jordi's review. Thanks to both of you! On Thu, Apr 25, 2019 at 8:44 PM Yu Feng wrote: > diff --git a/hgext/histedit.py b/hgext/histedit.py > --- a/hgext/histedit.py > +++ b/hgext/histedit.py > @@ -1227,6 +1227,13 @@ def addln(win, y, x, line, color=None): >

Re: [PATCH V4] repoview: introduce a `experimental.extra-filter-revs` config

Queued. On Tue, Apr 23, 2019 at 11:34 PM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > Gentle ping on that patch. All the feedback from the previous round > should have been applied. > > On 4/17/19 4:37 PM, Pierre-Yves David wrote: > > diff --git a/mercurial/configitems.py b/mercur

Re: [PATCH 2 of 3] hgtagsfnodescache: inherit fnode from parent when possible

On Thu, May 2, 2019 at 3:05 PM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > > > On 5/2/19 11:55 PM, Martin von Zweigbergk wrote: > > > > > > On Thu, May 2, 2019 at 2:48 PM Pierre-Yves David > > mailto:pierre-yves.da...@ens-lyon.org>> > > > wrote: > > > > > > > > On 5/2/19 8:24

Re: [PATCH 2 of 3] hgtagsfnodescache: inherit fnode from parent when possible

On Thu, May 2, 2019 at 2:48 PM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > > > On 5/2/19 8:24 PM, Martin von Zweigbergk wrote: > > > > > > On Thu, May 2, 2019 at 9:37 AM Pierre-Yves David > > mailto:pierre-yves.da...@ens-lyon.org>> > > > wrote: > > > > # HG changeset patch > >

Re: [PATCH 2 of 3] hgtagsfnodescache: inherit fnode from parent when possible

On Thu, May 2, 2019 at 9:37 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > # HG changeset patch > # User Pierre-Yves David > # Date 1552263020 -3600 > # Mon Mar 11 01:10:20 2019 +0100 > # Node ID eac353183daaef0a503da8cd72b8df43f54d7fb8 > # Parent a753bc019c1ad7c5661a050adc

Re: [PATCH] httppeer: make sure we limit argument for older server not supporting batch

On Thu, Apr 25, 2019 at 12:58 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > > > On 4/25/19 6:03 AM, Martin von Zweigbergk wrote: > > > > > > On Wed, Apr 24, 2019 at 7:25 PM Gregory Szorc > > wrote: > > > > On Wed, Apr 24, 2019 at 12:29 AM Pier

Re: [PATCH] httppeer: make sure we limit argument for older server not supporting batch

On Wed, Apr 24, 2019 at 7:25 PM Gregory Szorc wrote: > On Wed, Apr 24, 2019 at 12:29 AM Pierre-Yves David < > pierre-yves.da...@ens-lyon.org> wrote: > >> # HG changeset patch >> # User Pierre-Yves David >> # Date 1556049342 -7200 >> # Tue Apr 23 21:55:42 2019 +0200 >> # Node ID 26f277f0f415

Re: [PATCH 1 of 2 V2] peer: introduce a limitedarguments attributes

On Tue, Apr 23, 2019 at 11:35 PM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > > > On 4/17/19 8:33 PM, Martin von Zweigbergk wrote: > > > > > > On Wed, Apr 17, 2019 at 10:41 AM Pierre-Yves David > > mailto:pierre-yves.da...@ens-lyon.org>> > > > wrote: > > > > > > > > On 4/17/19

Re: [PATCH 4 of 4 V3] verify: also check full manifest validity during verify runs

On Wed, Apr 17, 2019 at 8:25 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > # HG changeset patch > # User Pierre-Yves David > # Date 1551881213 -3600 > # Wed Mar 06 15:06:53 2019 +0100 > # Node ID 15d38aadce0e1a4cc526e9bbbc42a158c263df53 > # Parent 9bec7491e9b4cabdfa4d264e5

Re: [PATCH 1 of 2 V2] peer: introduce a limitedarguments attributes

On Wed, Apr 17, 2019 at 2:38 PM Martin von Zweigbergk wrote: > > > On Wed, Apr 17, 2019 at 2:33 PM Joerg Sonnenberger wrote: > >> On Wed, Apr 17, 2019 at 11:33:45AM -0700, Martin von Zweigbergk via >> Mercurial-devel wrote: >> > Question 3: Does httppostargs swi

  1   2   3   4   5   6   7   8   9   10   >