726bd0b612a2 does the same thing.

In D7101#104151, @martinvonz wrote:

I can’t tell from my phone, but should the matcher in getworkqueue and the status call in pathstofix also be adjusted? (Not sure if there are others.)

No, that matcher (it's the same instance that's passed between them) is created based on pats and opts, i.e. command line arguments.

In D7065#104119, @martinvonz wrote:

I talked to @hooper about this and they agreed that using repo-relative paths is almost always what the user wants. I've sent D7101 for that.

The part of the help text that documents :pattern and points to hg help patterns should probably explicitly state that they are all relative to repo root, regardless of what the latter says.

I'm baffled, but this causes test-install.t to fail on Windows:

In D7065#103834, @martinvonz wrote:

It's unfortunate that this is necessary. I'll see if I can fix fix.py to always interpret patterns relative to the repo root.

Should this print a warning when it's loaded? I suspect the number of people reading the source or extension help once they start using it is significantly less than the number that read the output.

In D6876#102925, @marmoute wrote:

The feature seens pretty usful, but is also a potential foot-gun/data-loss engine. I think it is useful to take the feature, but maybe with proper documentaiton warning and turned of by efaut. I made a couple of comment about the implementation.

In D6989#102437, @indygreg wrote:

Question: should this checking be performed in exchange.push or at the command layer?
(I'm not sure of the answer.)

Here's a case I stumbled upon that is a problem. It looks like it thinks it isn't in the middle of an update, but .hgsubstate isn't put back to the pre-update state.

In D6709#100618, @marmoute wrote:

In D6709#99199, @av6 wrote:

I'm strongly -1 on adding qualifiers straight to the keys. The primary usage scenario here is scripts (as explained in issue6014) -- regular users lived without this feature for years and didn't care (enough to file a bug) about getting all config options, or their default values, or the experimental status (they could and still can read it in hg help config). --registered is needed for things like shell completions, and the output needs to be clear and parseable (and consistent with what regular showconfig shows).

I disagree that the primary use is script only. As a suer I have wanted this for a long time and I am happy to finally have a way to get this data without grepping the source.

Even adding "(default: x)" to values already complicates the parsing process to get multiple config options in a script. Yeah, a script can get individual values one by one, but it can take ages because of the start-up time (again, this is important for interactive scripts like shell completions).

May we should drop the (default: x) part unless --verbose is specified. That would make sense to me. Since experimental/devel/debug(/deprecated?) only appears with --verbose that might work just fine for you ?

In D6846#100478, @mharbison72 wrote:

This seems to work (though the shebang line hack is painful)- until the original python build directory is deleted. Then a lot of things complain about unsupported hash type for md5 and sha{1,224,256,384,512}. Other modules like json can be imported with the installed python executable. I grepped around for the build directory, and it is in a bunch of *.so files (though this could be __FILE__ for all I know). Any ideas?

This seems to work (though the shebang line hack is painful)- until the original python build directory is deleted. Then a lot of things complain about unsupported hash type for md5 and sha{1,224,256,384,512}. Other modules like json can be imported with the installed python executable. I grepped around for the build directory, and it is in a bunch of *.so files (though this could be __FILE__ for all I know). Any ideas?

Oops, meant to flag changes needed too.

In D6735#100392, @durin42 wrote:

This looks good to me. Does anyone else have comments? @mharbison72 are you happy with the subrepo test coverage?

2. In lfs, where we deal with standins and mutating status.

In D6754#100159, @durin42 wrote:

This is a start, but I suspect where we should end up with this is downloading and compiling the whole Python distribution, rather than relying on a virtualenv to be portable?

In D6828#100192, @pulkit wrote:

In D6828#100190, @mharbison72 wrote:

I'd like to port --interactive.

That will be great. https://phab.mercurial-scm.org/D6005 should help :)

In D6828#100139, @pulkit wrote:

I guess --interactive is the only flag left which is extra in evolve version, right?

In D6754#99255, @indygreg wrote:

This looks promising.
I don't want to tell you not to work on this, but my bold plan is to get Mercurial using PyOxidizer and leaning on PyOxidizer for packaging. This will require shipping a Python 3 Mercurial, however.

I missed the debug one too, sorry. (Although I’m not sure why that also isn’t devel., so maybe it isn’t a big deal. Curious what others think.)

Should we hide devel.* like we do experimental when verbose isn’t applied? Presumably we don’t want regular users to know about them.

Maybe I’m looking at something wrong, but it looks like a couple references to “the shelve” snuck in after the last edit in diff 16017.

In D6643#97250, @valentin.gatienbaron wrote:

In D6643#97247, @mharbison72 wrote:

I ran this on the repo that was giving me fits last summer, and it stayed consistent up until just after the point where there was an octopus fixup merge. I suspect the logic in that part of convert is too loose (i.e. it should be dropping files in the fixup merge that were already in the first merge if there weren't changes in the 3rd branch), but wasn't able to write a simple test. (The original repo was in bzr, converted to hg, and then I had to reconvert to lfs.) I've been swamped at work, so I don't have time to dig into it. But no sense in holding this up, as there doesn't seem to be a regression here.

I didn't quite understand. Are you saying your convert call cause hashes to change after this octopus merge, but it's not caused by my change, i.e. hg behaves this way even before?

In D6613#97136, @valentin.gatienbaron wrote:

@mharbison72 I dealt with the problem of convert in the previous commit. I didn't add a config option to disable the new code path, because it's really awkward to document, and I think it would be annoying to use if I made more fixes (the other case where files are spuriously listed, involving exec bits, probably has little impact on repo size/pull performance but it may be worth fixing anyway because it causes confusion). But if there are downsides to what I did, the config option is still on the table.

The update worked for me, thanks.