Superseded by D9950

This still adds all of the function call overhead even when the feature is not used. I also don't like that this check is done repeatedly e.g. during an unbundle. I don't think I would mind checking the size once per revlog on the first write, but not repeatedly.

In D9881#150425, @pulkit wrote:

This should be marked as an API change or a entry should be added in releasenotes.

The strange thing is that I see the Python 2 failures on the Heptapod CI and the Python 3 failures on OpenSuSE. Both with the system Python and the pkgsrc one in the later case. IMO if we want to do testing for PIP, it should be on the CI only.

I didn't measure it, but I don't expect it to make a difference. rev->node is the cheap mapping in all cases, it is the reverse that can be expensive.

I like the change.

I like the change.

LGTM

Actually, I believe this really belongs into a/the debug namespace, not admin. It's a much lower level than all other tools and not a user interface in any form.

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 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.

The output is entirely valid according to the git format specification. It is also entirely valid under the formatting rules for email addresses, which was supposed to be the origin of this identifiers. As such, I see no reason to change anything.

In D9780#149086, @marmoute wrote:

I like the fact we now take a rev as argument. However two discussion remains:

• could/should we stop passing the changelogrevision as argument ?

As discussed, move to using revision for the new function. Most of the prep work is factored out into smaller changesets, except changegroup.py, since that would create a small penalty by itself for no good reason. The goal for follow-up changes is to provide the revision from _addrevision directly (either instead or in addition to the node).

In D9780#148725, @marmoute wrote:

• it pass around quite high level object where I think rev would be more appropriate,

Passes now

LGTM

Superseded by D9778, D9779, D9780 and D9781.