merge: use bid merge by default (BC) In most cases merges will work exactly as before. The only difference is in criss-cross merge situations where there is multiple ancestors. Instead of picking an more or less arbitrary ancestor, it will consider both ancestors and pick the best bids. Bid merge can be disabled with --config merge.preferancestor='!'.

changectx: skip all invalid merge.preferancestor values A better fix for 17011b36aac7 that will ignore other kinds of "invalid" revisions.

revset: rely on built in iterator when possible in _generatorset.__iter__ Doing manual iteration is expensible. We rely on built in list iteration whenever possible. The other case has to become a closure we cannot have a both yield and return in the same function.

revset: prefetch an attribute in _generatorset.__iter__ Python's attribute lookup are expensible, lets do less of them. This gives us a 7% speedup on this revset iteration (from 0.063403 to 0.059032)

templater: add count template filter, plus tests Previously there was no way of telling how much children or bookmarks or tags a certain changeset has in a template. It was possible to tell if a changeset has either 0 or not 0 bookmarks, but not to tell if it has 1 or 2 of them, for example. This filter, simply named count, makes it possible to count the number of items in a list or the length of a string (or, anything that python's len can count). E.g.: {children|count}, {bookmarks|count}, {file_adds|count}. Testing the filter on node hash and shortened node hash is chosen because they both have defined length. As for lists of strings - children, tags and file_adds are used, because they provide some variety and also prove that what's counted is the number of string items in the list, and not the list stringified (they are lists of non-empty, multi-character strings). Additionally, revset template function is used for testing the filter, since the combination is very flexible and will possibly be used together a lot. (The previous version of this patch had an incorrect email subject and was apparently lost - patchwork says the patch has been accepted, but it's not so. The changes between that and this patch are minimal: now the filter does not disturb the alphabetical order of function definitions and dict keys.)

push: update bookmarks (on server) within a transaction A nice side effect is that bookmarks sent through bundle2 are updated within the same transaction as all other changes.

pull: perform bookmark updates in the transaction

bookmark: add a `bmstore.recordupdate` to plug bookmarks into the transaction Instead of manually writing bookmarks when they are updated, we can just record this update to the transaction and rely on it to update the on-disk file.

bookmarks: split bookmark serialization and file handling If we want to handle bookmarks in a transaction we need to decouple the file handling and the actual production of the content. This is similar to how we handle phases in transaction.

transaction: allow generating file outside of store We allow a vfs argument to `addfilegenerator`. This allows generating files outside of the store directory like bookmarks. However, this is not really working since we do not have the infrastructure to backup and restore files outside of store. By chance, the bookmark file is already backed up by another mechanism so we can restrict this new feature to bookmarks (which is our only interest here) and proceed.

transaction: work around and document issue with file backup The backup restoration is actually hard-coded for the main file. And this hard-coded list is the only one used when repairing an interrupted transaction from another process. Solving this problem is out of the scope of this series so we document it and work around its implications.

bundle2: remove an explicit packing The final writing of the empty part was done explicitly. We now using proper pack call using symbolic constant. This open simple change in the bundle2 format.

bundle2: split test in two We split the test between the one dedicated to the binary format and the one dedicated to checking the exchange of data using pull and push.

pull: merge bookmark updates and imports We do all the things in one go now, updating existing bookmark, adding new ones, and overwriting the ones explicitly specified for --bookmark. This impacts the tests by removing some duplicated or unnecessary output.

pull: gather explicit bookmark pulls with bookmark updates There is no reason to make them at different times. So we gather them. This is the first step toward merging them.

subrepo: stop pulling bookmark manually Bookmark pulling is now done with all the other pull steps in the `exchange.pull` function.

pull: retrieve bookmarks through bundle2 We can retrieve any pushkey namespace through bundle2. So we also ask for bookmark data and use them to update the local repo.

pull: retrieve bookmarks before obsmarkers Retrieving bookmarks before obsmarkers will avoid turning some changesets hidden right before making them visible again if a bookmark keeps them visible.

pull: move bookmark pulling into its own function This requires adding an attribute on the pulloperation object. The bookmark pulling is protected behind a "todostep" as other steps of pull.

pull: perform the todostep inside functions handling old way of pulling This matches what is done during push.

bookmark: remove now unused `pushtoremote` function Everything is unified in the push discovery now.

push: gather all bookmark decisions together The discovery phases for bookmarks now use the list of explicitly pushed bookmarks to do addition, removal and overwriting. Tests are impacted because this reduces the amount of listkeys calls issued, removes some duplicated messages and improves the accuracy of some messages.

push: prepare the issue of multiple kinds of messages To gather all the bookmark pushing actions together, we need code performing those actions to be ready for them. We need to be able to produce different messages for different actions.

push: set bkresult when pushing bookmarks through bundle2

clone: remove duplicated bookmark pulling Now that all clone methods (copy, pull and push) also transport bookmarks, we can safely drop the manual pulling that was performed during clone.

clone: explicitly push bookmarks when cloning from local to remote We need to explicitly push all local bookmarks when doing the clone from a local repo to a remote one through ssh. This will let us remove the manual export of bookmarks in clone and rely on the official exchange in push and pull instead.

clone: copy `.hg/bookmarks` during copy clone Now that the standard pull function includes bookmarks, we need to ensure that a copy clone also copies the bookmarks. This will let us drop the manual bookmark pulling done independently during a clone.

pull: move bookmark movements inside the `exchange.pull` There is no reason for bookmarks to get a special treatment. As a first step we move the code as is in the `exchange.pull` function. Integration with the rest of the flow will come later. Adding bookmarks to pull means that most clone paths are now pulling bookmarks through pull. We ensure that bookmark-update messages are properly suppressed in that case. In test-pull-http.t the 'requesting all changes' message disappear because we now get the authentication error on the `listkeys`command before such message is printed.

bookmarks: allow `updatefromremote` to be quiet This will be useful to use the function during clone (clone is not printing any bookmark data right now)

util: fix sorteddict.pop When using `.pop` on such object the list was not cleared of the popped key, leading to crash.