For the NetBSD repository, a trivial test with the new cache:

Friendly ping

Adjusted for most of the review comments. Added a test that books are left alone, since they will not be active in the interesting cases. I'm not touching any existing phases, so I'm not sure if I should do anything about phase testing?

It's used in reportphasechanges and that accidently turned O(n) into O(n^2). I noticed it when trying a clone --narrow of the NetBSD repo, since it hung for quite a while in that loop.

In D3439#58405, @martinvonz wrote:

Do you think we should call it commonpath() or commondir() instead in case we want commonprefix() to work for any string in the future (and not care about path separators)?

If we want to go with a --close flag, I think the most natural place would actually be hg heads. This is not really a branch operation after all, but about cutting off heads. At the same time, none of those options would allow specifying a commit message naturally.

It doesn't seem to fit the argument schema for hg branch at all. I'm open for better places, but I couldn't think of a consistent place.

Similar to Martin's question, I would like to allow streaming clones without any locks. For that to work, one party needs to know how to truncate additional undesired data. That can be fully done by the client or the client could send a size or revision hint to the server.

{str|commonprefix} is not really interesting since it is naturally an iterable of text. The others are covered, the routine tries to optimize a couple of common cases as well now.

I don't really disagree that the existing option naming is a bit stupid. There are useful points for including the compression level as part of the bundle spec, but I don't think that replaces the need for a config option for sane defaults.
As I said on IRC, a consistent approach for the three places where compression is used would be useful:

• standalone "hg bundle" operations
• wire compression
• reflog compression

Updated to the current tree. One open question is an interaction with the narrow extension. Running the narrow tests will show an additional round trip.