# HG changeset patch
# User Patrick Mezard <patrick@mezard.eu>
# Date 1328636836 -3600
# Node ID fcc01604f7a6c7cddfcc2d8e14c9089e3d229897
# Parent  b5a5c7ce4d1dc523d5178157de160af0897472cf
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 ]

diff -r b5a5c7ce4d1d -r fcc01604f7a6 tests/test-keyword.t
--- a/tests/test-keyword.t	Wed Feb 08 16:56:00 2012 +0000
+++ b/tests/test-keyword.t	Tue Feb 07 18:47:16 2012 +0100
@@ -556,7 +556,6 @@
 Commit and show expansion in original and copy
 
   $ hg --debug commit -ma2c -d '1 0' -u 'User Name <user@example.com>'
-  invalidating branch cache (tip differs)
   c
    c: copy a:0045e12f6c5791aac80ca6cbfd97709a88307292
   overwriting c expanding keywords