Sat, 24 Oct 2015 09:47:33 +0100 hgweb: remove unused colorPart() from mercurial.js
Anton Shestakov <av6@dwimlabs.net> [Sat, 24 Oct 2015 09:47:33 +0100] rev 26867
hgweb: remove unused colorPart() from mercurial.js Looks like the function wasn't ever used since its introduction in 0dba955c2636, since setColor() below always used "rgb(255, 255, 255)" notation which doesn't need hex digits.
Sun, 18 Oct 2015 18:49:59 +0200 test: enforce non-general delta in 'test-generaldelta.t'
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 18 Oct 2015 18:49:59 +0200] rev 26866
test: enforce non-general delta in 'test-generaldelta.t' If general delta becomes the default, we need to be explicit about what we want to be tested.
Tue, 20 Oct 2015 15:27:56 +0200 test: enforce bundle1 in 'test-push-cgi.t'
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:27:56 +0200] rev 26865
test: enforce bundle1 in 'test-push-cgi.t' This test is checking bundle1 application, therefore we have to enforce the generated bundle to be a bundle1.
Sun, 18 Oct 2015 18:42:09 +0200 test: enforce v1 in 'test-debugbundle.t'
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 18 Oct 2015 18:42:09 +0200] rev 26864
test: enforce v1 in 'test-debugbundle.t' This test is about bundle1 and should remain so when we move to generaldelta by default.
Tue, 20 Oct 2015 02:39:42 +0200 test: enforce bundle1 in "test-commit-interactive.t"
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 02:39:42 +0200] rev 26863
test: enforce bundle1 in "test-commit-interactive.t" This test generate a bundle to get a binary file to commit. We should ensure this binary file remains the same when we move to general delta as default.
Fri, 06 Nov 2015 09:48:24 -0800 discovery: factor out calculation of heads to not warn about
Ryan McElroy <rmcelroy@fb.com> [Fri, 06 Nov 2015 09:48:24 -0800] rev 26862
discovery: factor out calculation of heads to not warn about In addition to taking a step towards getting an unreasonably large function factored into smaller, more manageable functions, this will allow extensions such as remotenames have more control over what pushes are allowed or not.
Fri, 06 Nov 2015 11:08:11 -0500 hooks: back 9f272bf3b342 out stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 06 Nov 2015 11:08:11 -0500] rev 26861
hooks: back 9f272bf3b342 out Changeset 9f272bf3b342 alters the 'HG_PENDING' mechanism to be "always" there. This change is made under the assumption than we previously did it only when "writepending() actually wrote something". This assumption was wrong, 'writepending()' informs of pending changes the first time something is written and for all following calls. We back this change out to restore the former behavior, which was already correct.
Wed, 04 Nov 2015 15:17:52 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 04 Nov 2015 15:17:52 -0600] rev 26860
merge with stable
Tue, 03 Nov 2015 17:13:27 -0800 hooks: fix hooks not firing if prechangegroup was set (issue4934) stable
Durham Goode <durham@fb.com> [Tue, 03 Nov 2015 17:13:27 -0800] rev 26859
hooks: fix hooks not firing if prechangegroup was set (issue4934) We need to call delayupdate again after writing to the changelog. Otherwise the prechangegroup hook consumes the delayupdate subscription and future hooks don't see the pending changes (see issue 4934 for more details). Adds a test that triggers the prechangegroup hook before the pretxnchangegroup hook and verifies that the output of pretxnchangegroup doesn't change.
Tue, 03 Nov 2015 16:58:13 -0800 hooks: always include HG_PENDING stable
Durham Goode <durham@fb.com> [Tue, 03 Nov 2015 16:58:13 -0800] rev 26858
hooks: always include HG_PENDING Previously we would only include HG_PENDING in the hook args if the transaction's writepending() actually wrote something. This is a bad criteria, since it's possible that a previous call to writepending() wrote stuff and the hooks want to still see that. The solution is to always have hooks execute within the scope of the pending changes by always putting HG_PENDING in the environment.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip