Closing the peer is what I was describing as solution 3 in D9019. But I think I was wrong in saying that it doesn't help with calls to logtoprocess in the middle of commands. I also just noticed that does that, in fact. I'll try and find some time to do that.

What's holding this back is lack of py2 compatibility. Although maybe I want to wait it out at this point. Do we expect to drop py3 in a few days, after 5.7 is released for instance?

In D9789#149346, @indygreg wrote:

I'm -0 on this change. Caches are caches and IMO should only be populated on demand.

I'm not going to review this right now, but I have prior art at https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-February/093657.html and https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-May/097960.html that might be worth a read. I believe the wiki page on this format only contains a subset of the deficiencies I outlined in the 1st link.

This is meant for stable, to avoid a partial installation.

So if I send an email, using thunderbird, 9 folders or gmail and look at the email source the email name is not quoted.
All I ask is that hg behaves the same way. That should not be took much to ask?

In D9848#149355, @joerg.sonnenberger wrote:

Horrible parsing code, but not relevant for here. I gave the reasons why the original code used "", but I don't care either way if git doesn't fall apart anymore than already does when an address is not pretending to be a mail.

Horrible parsing code, but not relevant for here. I gave the reasons why the original code used "", but I don't care either way if git doesn't fall apart anymore than already does when an address is not pretending to be a mail.

The -- also bothers me and I came here to see if it had been discussed before accepting this patch.

In D9808#149349, @indygreg wrote:

Shouldn't this patch be checking for the existence of the windows_curses package instead?

Shouldn't this patch be checking for the existence of the windows_curses package instead?

I'm -0 on this change. Caches are caches and IMO should only be populated on demand.

I mostly support this change. However, a supposed no-op upgrade may still result in differences! For example, if we change the algorithm for computing how revlog deltas are computed without actually changing the storage semantics, performing a no-op upgrade would migrate the store to use the new code.

In D9516#149033, @mharbison72 wrote:

Big picture, why do we need to be able to tell namespace parts from command parts?

To make sure the user understand they are stepping in an entire different realm with different rules.
In the standard namespace (no prefix) we garantee (or aims at) the lack of footgun and excellent backward compatibility.
The debug namespace should not be somewhere any normal user ever have to go (at least without a responsible staff member)
The admin namespace will have its own rules and its own "be careful, this is not a "normal" situation to be there.
So we want something more distincting than just a simple - that we could have for "command group" or readability like phab-send, phab-read, etc.

So it sounds like more of a convention for these behavior properties than say, commands in the admin group requiring --yes-i-know-this-may-eat-my-data. We'll have to have to figure out how to convey that somehow. I see admin, for example, and think "I'm in charge of making this work for my group, and it sounds like it does what I want, so it's for me and just some extra characters to type". I don't have any suggestions on how to highlight these behaviors ATM.

In D9825#149333, @durin42 wrote:

Do you think we should go ahead and apply the local patch then until we can update the vendored copy?

Do you think we should go ahead and apply the local patch then until we can update the vendored copy?

In D9825#149257, @durin42 wrote:

Yes, please remove the python-zstandard changes from here, and send them directly to @indygreg upstream for that.

Finds the author command
https://github.com/git/git/blob/7f7ebe054af6d831b999d6c2241b9227c4e4e08d/builtin/fast-import.c#L2689

The basic concern I have here is that I have stepped on git's toes here before and the field is nowhere near as free text as it is supposed to be according to the specification. So any change should at least double check what the git code is actually doing, because it doesn't do the same as the documentation from what I have seen. Case in point is the data handling, where git does distingiush between +0 and -0.

Should we add a test that, if git-fast-import is available, actually tries the import and verifies that things look reasonable?

Yes, please remove the python-zstandard changes from here, and send them directly to @indygreg upstream for that.

Couple of changes from this patch can be separated and send individually as prepare for revlog v2 which will help speed up review.

The contrib/zstandard/ changes should be dropped from this patch. IIRC, Victor already created a PR for that.

So just for kicks I did hg fastexport on my dhcpcd repo where the author names look fine.
I then did hg fastimport (3rd party plugin) on the resultant fast-import file generated from the above.

Using git to create a fast-import, the comitter is never quoted.
Again, using git to import a quoted comitter name, preserves the quotes.
Using git log to display the import, the comitters name appears as "Roy Marples" <roy@marples.name> which just looks wrong.