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.

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.