User Details
- User Since
- Dec 6 2017, 9:25 AM (168 w, 3 d)
Thu, Feb 25
Wed, Feb 24
Wed, Feb 17
Superseded by D9950
Fri, Feb 12
Thu, Feb 11
Fri, Feb 5
Thu, Feb 4
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.
Tue, Feb 2
Mon, Feb 1
Sun, Jan 31
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.
Sat, Jan 30
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.
Jan 27 2021
I like the change.
I like the change.
LGTM
Jan 26 2021
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.
Jan 25 2021
Jan 24 2021
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.
Jan 22 2021
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.
Jan 21 2021
Jan 20 2021
Jan 19 2021
Jan 18 2021
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).
Jan 16 2021
Jan 15 2021
Passes now
LGTM