Wed, 30 Oct 2013 19:45:14 +0100 rebase: fix selection of base used when rebasing merge (issue4041) stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 30 Oct 2013 19:45:14 +0100] rev 19969
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
Tue, 29 Oct 2013 21:54:49 +0200 doc: fix internal date sample (issue4072) stable
Pavlos Touboulidis <pav@pav.gr> [Tue, 29 Oct 2013 21:54:49 +0200] rev 19968
doc: fix internal date sample (issue4072)
Mon, 28 Oct 2013 22:34:07 +0100 largefiles: use 'remote'/'local' in merge prompts like in other merge prompts stable
Mads Kiilerich <madski@unity3d.com> [Mon, 28 Oct 2013 22:34:07 +0100] rev 19967
largefiles: use 'remote'/'local' in merge prompts like in other merge prompts Prompts like foo has been turned into a largefile use (l)argefile or keep as (n)ormal file? was not as clear as the usual prompts that use 'remote' or 'local' to explain what happened on which side ... especially not when used to the normal prompts. "as" could also indicate that it would be possible to take the content of the largefile and somehow put it into the normal file. It could make it more clear that it was a choice between one side or the other. For consistency we will now phrase it like: remote turned local normal file f into a largefile use (l)argefile or keep (n)ormal file?
Mon, 28 Oct 2013 22:34:05 +0100 largefiles: systematic testing of merges to/from largefiles stable
Mads Kiilerich <madski@unity3d.com> [Mon, 28 Oct 2013 22:34:05 +0100] rev 19966
largefiles: systematic testing of merges to/from largefiles 427ce5633c1c fixed one problem with update and added a test case for it. The test coverage was thus insufficient before that. To make sure we have good test coverage in this area we add systematic testing of all cases of merges that may or may not change normal files to largefiles or vice versa. The tests shows some annoying extra merge prompts in some cases, but these prompts are hard to avoid and they are now "safe" - they do not leave the system in a confused inconsistent state.
Wed, 23 Oct 2013 23:42:13 +0800 check-code: fix no-check-code skip message - obfuscation was too obscure stable
Mads Kiilerich <madski@unity3d.com> [Wed, 23 Oct 2013 23:42:13 +0800] rev 19965
check-code: fix no-check-code skip message - obfuscation was too obscure
Tue, 29 Oct 2013 01:03:43 +0900 shelve: remove useless and incorrect code paths for file access stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 29 Oct 2013 01:03:43 +0900] rev 19964
shelve: remove useless and incorrect code paths for file access This patch removes code paths in "shelvedfile.opener()", because: - explicit "vfs.mkdir()" invocation is useless "vfs.__call__()" for modes other than "read" creates parent directory of target file automatically by "util.ensuredirs()". - mode checking in "except IOError" code path is useless ENOENT occurs only for "read" mode, because target file is created forcibly for other modes. - there is no explicit "return" statement in the code path for "except IOError" if "mode[0] in 'wa'" this is incorrect, because None may be returnd unexpectedly, even though it seems the EEXIST case in the directory creation race for ".hg/shelved" and is very rare. this directory creation race is also treated in "util.ensuredirs()".
Tue, 29 Oct 2013 01:03:43 +0900 shelve: disallow commit while unshelve is in progress stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 29 Oct 2013 01:03:43 +0900] rev 19963
shelve: disallow commit while unshelve is in progress Before this patch, commit is allowed even while unshelve is in progress. In the other hand, "hg unshelve --abort" and "hg unshelve --continue" check whether parent revisions of the working directory have changed or not since last "hg unshelve", and abort without clearing state for unshelve in progress if they have. This causes that accidental commit makes clearing state for unshelve difficult in ordinary ways. This patch disallows commit while unshelve is in progress for consistency.
Wed, 30 Oct 2013 16:03:42 -0500 bdiff: avoid a memory error on malloc failure stable
Matt Mackall <mpm@selenic.com> [Wed, 30 Oct 2013 16:03:42 -0500] rev 19962
bdiff: avoid a memory error on malloc failure
Wed, 23 Oct 2013 13:12:48 -0700 shelve: use rebase instead of merge (issue4068) stable
Durham Goode <durham@fb.com> [Wed, 23 Oct 2013 13:12:48 -0700] rev 19961
shelve: use rebase instead of merge (issue4068) Previously, shelve used merge to unshelve things. This meant that if you shelved changes on one branch, then unshelved on another, all the changes from the first branch would be present in the second branch, and not just the shelved changes. The fix is to use rebase to pick the shelve commit off the original branch and place it on top of the new branch. This means only the shelved changes are brought across. This has the side effect of fixing several other issues in shelve: - you can now unshelve into a file that already has pending changes - unshelve a mv/cp now has the correct dirstate value (A instead of M) - you can now unshelve to an ancestor of the shelve - unshelve now no longer deletes untracked .orig files Updates tests and adds a new one to cover the issue. The test changes fall into a few categories: - I removed some excess output - The --continue/--abort state is a little different, so the parents and dirstate needed updating - Removed some untracked files at certain points that cluttered the output
Fri, 25 Oct 2013 01:14:18 +0900 doc: put text into header of 1st column in table to generate page correctly stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 25 Oct 2013 01:14:18 +0900] rev 19960
doc: put text into header of 1st column in table to generate page correctly >From the table without header text of 1st column, docutils generates the table with fully empty header row.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip