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.

Pilot error

There was a longish discussion on IRC about this. The problem is that the flags by themselves do not document the interaction of -r and -b or multiple instances of either at all. The change was a compromise trying to address that.

I haven't seen a performance difference for regular runs, but it does show up in profiles, so eliminating it avoids wasting mental power by developers down the line.

No, the change to yield a bool first is not strictly necessary for the rest of the logic. But it cheaply kills the need for the rewindhunk generator, i.e. it cuts a layer of indirection cheaply.

I don't completely trust my numbers here, but it seems to give at least 3-4% for diffing netbsd-7 and netbsd-8.