Wed, 22 Jan 2014 16:34:36 +0100 i18n: do not translate rst syntax .. note:: stable
Simon Heimberg <simohe@besonet.ch> [Wed, 22 Jan 2014 16:34:36 +0100] rev 20321
i18n: do not translate rst syntax .. note:: .. note:: is rst syntax which must not be translated. Fix this in the translations. This is not the first time this happens, so there should be a note for the translator. A later patch will change the generation of the po files to write this automatically. A test in i18n/check-translation.py could help as well.
Mon, 27 Jan 2014 16:34:00 -0200 i18n-pt_BR: synchronized with 268a5ab5c27b stable
Leonardo Bueno Postacchini <notivago@gmail.com> [Mon, 27 Jan 2014 16:34:00 -0200] rev 20320
i18n-pt_BR: synchronized with 268a5ab5c27b
Sun, 24 Nov 2013 02:17:17 +0100 subrepo: make it possible to update to hidden subrepo revisions stable
Angel Ezquerra <angel.ezquerra@gmail.com> [Sun, 24 Nov 2013 02:17:17 +0100] rev 20319
subrepo: make it possible to update to hidden subrepo revisions When a subrepo revision was hidden it was considered missing and mercurial was unable to update to the corresponding parent revision. Instead warn the user of the problem and let it choose what to do (the default is to udpate anyway).
Sun, 24 Nov 2013 02:13:00 +0100 subrepo: remove unnecessary else clause in hgsubrepo._get stable
Angel Ezquerra <angel.ezquerra@gmail.com> [Sun, 24 Nov 2013 02:13:00 +0100] rev 20318
subrepo: remove unnecessary else clause in hgsubrepo._get This revision has no behaviour change. It simply removes an unnecessary else that follows an if / return block. The change looks big because a big chunk of code has been unindented one level.
Sun, 24 Nov 2013 02:10:14 +0100 subrepo: do not try to get hidden revisions stable
Angel Ezquerra <angel.ezquerra@gmail.com> [Sun, 24 Nov 2013 02:10:14 +0100] rev 20317
subrepo: do not try to get hidden revisions If a subrepo revision is hidden (because it was amended, for example) it does not make sense to try to "get" it from the remote subrepository. Note that in order to avoid making the change look bigger than it is, this adds an unnecessary else clause. This will be removed on a follow up patch.
Thu, 23 Jan 2014 19:08:26 +0100 parsers: fix 'unsigned expression is always true' warning (issue4142) stable
David Soria Parra <davidsp@fb.com> [Thu, 23 Jan 2014 19:08:26 +0100] rev 20316
parsers: fix 'unsigned expression is always true' warning (issue4142) On Mac OS gcc-llvm throws an -Wtautological-compare warning because flen is defined as an unsigned integer, therefore flen < 0 is always true.
Thu, 23 Jan 2014 14:06:15 -0600 wix: pull in new templates stable
Steve Borho <steve@borho.org> [Thu, 23 Jan 2014 14:06:15 -0600] rev 20315
wix: pull in new templates
Mon, 28 Jan 2013 15:16:49 +0100 phase: properly compute ancestors of --rev on push (issue3786) stable
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 28 Jan 2013 15:16:49 +0100] rev 20314
phase: properly compute ancestors of --rev on push (issue3786) Now that discovery is working on unfiltered changeset, I had a good occasion to look at that bug again. This let me realise that a trivial node vs rev comparision was the cause of this two years old bugsā€¦ Happy second birthday phases!
Thu, 23 Jan 2014 01:21:08 +0100 hgext: fix one typo in rebase stable
Simon Heimberg <simohe@besonet.ch> [Thu, 23 Jan 2014 01:21:08 +0100] rev 20313
hgext: fix one typo in rebase
Thu, 23 Jan 2014 01:29:50 +0100 templater: selecting a style with no templates does not crash (issue4140) stable
Simon Heimberg <simohe@besonet.ch> [Thu, 23 Jan 2014 01:29:50 +0100] rev 20312
templater: selecting a style with no templates does not crash (issue4140) Running `hg log --style compact` (or any other style) raised a traceback when no template directory was there. Now there is a message: Abort: style 'compact' not found (available styles: no templates found, try `hg debuginstall` for more info) There is no test because this would require to rename the template directory. But this would influence other tests running in parallel. And when the test would be aborted the wrong named directory would remain, especially a problem when running with -l.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip