Fri, 13 Apr 2018 09:26:28 -0700 evolve: don't pass stringified int to repo.__getitem__
Martin von Zweigbergk <martinvonz@google.com> [Fri, 13 Apr 2018 09:26:28 -0700] rev 3662
evolve: don't pass stringified int to repo.__getitem__ We were doing repo['-1'], which is now deprecated. Switch to repo['tip'], which is much clearer anyway (I initially thought this was nullrev and sent an incorrect patch until Pierre-Yves corrected me).
Wed, 11 Apr 2018 07:23:34 +0200 patch: offer the user a chance to fix the patch if it fails to apply
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 11 Apr 2018 07:23:34 +0200] rev 3661
patch: offer the user a chance to fix the patch if it fails to apply The experience is still not great, but better than purely dropping the changes.
Sun, 18 Mar 2018 23:48:06 +0530 amend: add a new flag `--patch` to `hg amend`
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 18 Mar 2018 23:48:06 +0530] rev 3660
amend: add a new flag `--patch` to `hg amend` This patch adds a new flag `--patch` to `hg amend` which pops up an editor with the patch of working directory parent which you can change, and when you exit the editor the patch with changes is applied to current working directory with old changeset being obsoleted in favour of new one created by the applied patch. If supplied filenames, only those filenames are present in the popped editor and rest files stay the same way in the commit as they were. The extension of the file which opens up in editor is '.diff', we cannot have it as '.patch' as there will be develwarns related to that. We need to change to patch core and undo some change to achieve this. The implementation does not use any core API rather it has picked chunks from API which are required. One main reason to not use core import API is that we have to change wdir parent before using patch.patch() which I will like to avoid to make sure we handle merge cases too. While writing this patch I have spend lot of time try to use internal API's to work for this but none of them served the purpose well. If I have time in future and work on similar problem again, I am going to write better high-level API's which uses patchstore to achieve this. A new test file test-amend-patch.t which contains a lot of testing of the feature.
Thu, 12 Apr 2018 13:30:28 +0800 stablerangecache: include units in ui.progress() calls
Anton Shestakov <av6@dwimlabs.net> [Thu, 12 Apr 2018 13:30:28 +0800] rev 3659
stablerangecache: include units in ui.progress() calls
Thu, 12 Apr 2018 13:28:30 +0800 stablerange: include units in ui.progress() calls
Anton Shestakov <av6@dwimlabs.net> [Thu, 12 Apr 2018 13:28:30 +0800] rev 3658
stablerange: include units in ui.progress() calls
Fri, 06 Apr 2018 20:00:43 +0530 tests: add test demonstarting issue5833 is fixed
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 06 Apr 2018 20:00:43 +0530] rev 3657
tests: add test demonstarting issue5833 is fixed Previous patch which fixed issue5832 also fixed issue5833 as the root cause for both was same. This patch adds test of issue5833 as well. CHANEGLOG entry is also added for the fixed issues.
Fri, 06 Apr 2018 20:13:27 +0530 utility: convert node from MultipleSuccessorsError to rev numbers (issue5832)
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 06 Apr 2018 20:13:27 +0530] rev 3656
utility: convert node from MultipleSuccessorsError to rev numbers (issue5832) utility.builddependencies() deals with rev numbers but MultipleSuccessorsError returns nodeid which breaks the function and also breaks instability resolution. Previou patch demonstrate the breakage. This patch makes sure we convert those nodeids to rev numbers before processing ahead.
Fri, 06 Apr 2018 15:35:57 +0530 tests: add a test demonstarting issue5832 traceback
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 06 Apr 2018 15:35:57 +0530] rev 3655
tests: add a test demonstarting issue5832 traceback The traceback will be fixed in upcoming patches.
(0) -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 tip