Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 15:09:06 +0100] rev 1791
open the mercurial-3.9 compat branch
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 15:08:03 +0100] rev 1790
prepare release 5.6.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 15:07:30 +0100] rev 1789
debian: fix version format
There was a small error in the debian packaging
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 15:04:54 +0100] rev 1788
merge with default to prepare the next version
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 15:02:59 +0100] rev 1787
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 31 Jan 2017 12:32:45 -0800] rev 1786
uncommit: don't lose copy information of remaining files (issue5403)
As reported in the issue, "hg uncommit" would lose copy information of
the files that remained in the commit. The problem was simply that the
a dict of copies was iterated as "src, dst in copies.items()" where it
should have been "dst, src ...".
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Jan 2017 16:50:19 +0100] rev 1785
merge with stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 25 Jan 2017 16:40:45 +0100] rev 1784
fold: cleanly abort on empty fold set (issue5453)
We now handle the empty set case, cleanly aborting instead of crashing with a
traceback. The message used match the output of 'hg push' in similar situation.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 23 Jan 2017 16:09:16 +0100] rev 1783
README: update changelog
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Jan 2017 13:47:49 -0800] rev 1782
fold: require --from flag for folding revisions to working copy
It's very easy to think that "hg fold 4::6" will fold exactly those
revisions. In reality, it will fold those *and* any revisions between
them and the working copy. To prevent users from making that mistake,
require the use of a new --from flag for folding revisions from the
given set to the working copy. With this change, I'm sure some users
will be surprised that the command can not be run without either
--from or --exact, but at least the consequences will be smaller (the
command simply aborts and the user can try again).