keyword: add extra datefilters in a single update call

Merge with stable

Merge with main

cmdutil: fix accidental name clash with revrange function The revrange function was used further up, and when a local variable is defined with the same name, the earlier call to revrange becomes a 'local variable used before assignment' error. The clash was introduced in 890ad9d6a169.

commands: fix update's help to be more accurate Branches can have multiple heads, so it doesn't make sense to speak of "the head of the current branch". What update really does is try to update to the *tip* of the current branch.

i18n: use encoding.colwidth() for correct column width Some encoding and language combinations (e.g.: UTF-8 and Japanese) cause encoding characters into sequence of bytes more than column width of them. So, encoding.colwidth() should be applied instread of len() on i18n strings. In addition to it, formatting by '%*s'/'%-*s' also uses "number of bytes" to calculate space padding size, and should be fixed, too.

merge with stable

log: slowpath: do not read the full changelog When in the slowpath, we are examining _all_ changesets in revs. We need to order reads so they happen increasingly for I/O performance. Increasing windows were used to read changelog backwards in a windowed manner, reading the changelog forward inside each window. But since no revision range was specified, it was equivalent to reading the full changelog, even if a single revision was passed to the commandline. When --removed is used, we _need_ to scan all changesets, but if we're only looking for file patterns, this is not necessary and we can stick to the revspec that was given to us.

log: remove increasing windows usage in fastpath The purpose of increasing windows is to allow backwards iteration on the filelog at a reasonable cost. But is it needed? - if follow is False, we have no reason to iterate backwards. We basically just want to walk the complete filelog and yield all revisions within the revision range. We can do this forward or backwards, as it only reads the index. - when follow is True, we need to examine the contents of the filelog, and to do this efficiently we need to read the filelog forward. And on the other hand, to track ancestors and copies, we need to process revisions backwards. But is it necessary to use increasing windows for this? We can iterate over the complete filelog forward, stack the revisions, and read the reversed(pile), it does the same thing with a more readable code.

log: refactor: test for ranges inside filerevgen