mq: restore _branchtags() fast path (issue3223) Since a5917346c72e, mq saves the nodeid of the first applied patch to cache/branchheads, which breaks the optimized cache handling introduced in fbf8320f25c8. The problem is the revision being committed is appended to mqrepo.applied after the commit succeeds, which means mqrepo._branchtags() performs a regular update and write the first applied patch to the branch cache. One solution is to set a context variable _committingpatch on the mqrepo while it is committing a patch and to take it in account when deciding to fast-path mqrepo._branchtags(). Not really elegant but it works. The changes to test-mq-caches.t reverse changes introduced by a5917346c72e. The cache should not have been updated with mq records. The changes to test-keyword.t are indirectly caused by a5917346c72e. Reported and analyzed by Yuya Nishihara <yuya@tcha.org> Notes: - qpush still makes a slow path _branchtags() call when checking heads. Maybe this can be optimized. - be careful when merging this patch in default as secretcommit() was renamed newcommit() right after the end of the code freeze. [ original upstream message ]

536c1797202d57efb77bea098e10968ff01602ce universal_scheme
ba000e29ecf3b8df09e0fd363a78cabbe3c2a78f cvs_scheme
1fe48bf82d056f1ece05baccab888357c10c5ab8 r0.1
2e930f84224222ad6514a3c5dc6e00350e199e92 very_cvs
99dc49c5bcfba9d5b412c5fa6d0bf3ba20d68df1 hgkw_standalone_setup
15e8cd7f5295728b089fc8ba236c0f079572fb1d nohook
0c8b7e5c25a6b9a0d2782eaa3748eb546f5a254f archive
0000000000000000000000000000000000000000 universal_scheme
0000000000000000000000000000000000000000 cvs_scheme
0000000000000000000000000000000000000000 r0.1
0000000000000000000000000000000000000000 very_cvs
0000000000000000000000000000000000000000 hgkw_standalone_setup
0000000000000000000000000000000000000000 nohook
0000000000000000000000000000000000000000 archive