transaction: register summary callbacks only at start of transaction (BC) We currently register summary callbacks every time localrepo.transaction() is called, so both when the transaction is started and when a nested transaction is created. That seems a little weirdly asymmetric, because the summary callbacks are thus not necessarily registred at the beginning of the outermost transaction, but they are only called when the outermost transaction closes (not when a nested transaction closes). I want to add another summary callback that records the repo state at the beginning of the transaction and compares to that when the transaction closes. However, because of the registration that happens when a nested transaction is created, that would need to go through extra trouble to not overwrite the callback and report the difference from the start time of the innermost transaction to the close of the outermost transaction. Also, the callbacks are registered with a name based on the order they are defined in the registersummarycallback(). For example, if both the "new changesets %s" and the "obsoleted %i changesets" hooks are registered, the first would be called 00-txnreport and the second would be called 01-txnreport. That gets really weird if registersummarycallback() gets called multiple times, because the last one wins, and a depending on which of the two callbacks get registered, we might hypothetically even overwrite on type of callback with another. For example, if when the outer transaction was started, we registered the "new changesets %s" callback first, and when the inner transaction was started, we registered only the "obsoleted %i changesets" callback, then only the latter message would get printed. What makes it hypothetical is that what gets registered depends on the transaction name, and the set of transaction names that we match on for the former latter message is a subset of the set of names we match on for the former. Still, that seems like a bug waiting to happen. That second issue could be solved independently, but the first issue seems enough for me to consider it a bug (affecting developers, not users), so this patch simply drops that extra registration. Note that this affects "hg transplant" in a user-visible way. When "hg transplant" is asked to transplant from a remote repo so it involves a pull, then the outermost transaction name is "transplant" and an inner transaction is created for "pull". That inner transaction is what led us to sometimes report "new changesets %s" from "hg transplant". After this patch, that no longer happens. That seems fine to me. We can make it instead print the message for all "hg transplant" invocations if we want (not just those involving a remote), but I'll leave that for someone else to do if they think it's important. Differential Revision: https://phab.mercurial-scm.org/D1866

--- a/mercurial/localrepo.py	Sun Jan 14 14:39:17 2018 -0800
+++ b/mercurial/localrepo.py	Wed Jan 10 14:00:23 2018 -0800
@@ -1134,7 +1134,6 @@
                 raise error.ProgrammingError('transaction requires locking')
         tr = self.currenttransaction()
         if tr is not None:
-            scmutil.registersummarycallback(self, tr, desc)
             return tr.nest()
 
         # abort here if the journal already exists

--- a/tests/test-transplant.t	Sun Jan 14 14:39:17 2018 -0800
+++ b/tests/test-transplant.t	Wed Jan 10 14:00:23 2018 -0800
@@ -354,7 +354,6 @@
   added 1 changesets with 1 changes to 1 files
   applying a53251cdf717
   a53251cdf717 transplanted to 8d9279348abb
-  new changesets 37a1297eb21b:8d9279348abb
   $ hg log --template '{rev} {parents} {desc}\n'
   2  b3
   1  b1
@@ -560,7 +559,6 @@
   added 2 changesets with 2 changes to 2 files
   applying a53251cdf717
   4:a53251cdf717 merged at 4831f4dc831a
-  new changesets 722f4667af76:4831f4dc831a
 
 test interactive transplant