Fri, 16 Mar 2018 12:10:15 -0700 hgweb: convert an assert to a ProgrammingError
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 16 Mar 2018 12:10:15 -0700] rev 36977
hgweb: convert an assert to a ProgrammingError Because assert may get optimized away. Differential Revision: https://phab.mercurial-scm.org/D2882
Fri, 19 Jan 2018 18:52:50 -0800 filemerge: give some variables in _xmerge more descriptive names
Kyle Lippincott <spectral@google.com> [Fri, 19 Jan 2018 18:52:50 -0800] rev 36976
filemerge: give some variables in _xmerge more descriptive names Differential Revision: https://phab.mercurial-scm.org/D2886
Thu, 15 Mar 2018 13:19:55 -0700 rebase: allow in-memory merge of the working copy parent
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Mar 2018 13:19:55 -0700] rev 36975
rebase: allow in-memory merge of the working copy parent Before this patch and when the rebase involved the working copy parent (and thus the working copy too), we would not do in-memory rebase even if requested to. The in-code comment explains that the reason had something to do with avoiding an extra update, but I don't know which update that refers to. Perhaps an earlier version of the code used to update to the destination before rebasing even if in-memory rebase was requested? That seems to not be done at least since aa660c1203a9 (rebase: do not bail on uncomitted changes if rebasing in-memory, 2017-12-07). To see if this still made it slower, I create a single tiny commit on top of one branch of the mozilla-unified repo (commit a1098c82 to be exact) and rebased it to another branch (commit d4e9a7be). Before this patch that took 11.8s and after this patch it took 8.6s (I only did two runs each, but the timings were very consistent). Differential Revision: https://phab.mercurial-scm.org/D2876
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip