Sun, 01 Oct 2017 05:28:54 -0400 Added signature for changeset 2f427b57bf90 stable
Augie Fackler <raf@durin42.com> [Sun, 01 Oct 2017 05:28:54 -0400] rev 34356
Added signature for changeset 2f427b57bf90
Sun, 01 Oct 2017 05:28:49 -0400 Added tag 4.3.3 for changeset 2f427b57bf90 stable
Augie Fackler <raf@durin42.com> [Sun, 01 Oct 2017 05:28:49 -0400] rev 34355
Added tag 4.3.3 for changeset 2f427b57bf90
Mon, 18 Sep 2017 10:54:00 -0700 rebase: move bookmarks with --keep (issue5682) stable 4.3.3
Jun Wu <quark@fb.com> [Mon, 18 Sep 2017 10:54:00 -0700] rev 34354
rebase: move bookmarks with --keep (issue5682) This is a regression caused by 3b7cb3d17137. We have documented the behavior in rebase help: Rebase will destroy original commits unless you use "--keep". It will also move your bookmarks (even if you do). So let's restore the old behavior. It is done by changing `scmutil.cleanupnodes` to accept more information so a node could have different "movement destination" from "successors". It also helps simplifying the callsite as a side effect - the special bookmark movement logic in rebase is removed. Differential Revision: https://phab.mercurial-scm.org/D727
Wed, 20 Sep 2017 09:32:26 -0700 cleanupnodes: rename "mapping" to "replacements" stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 20 Sep 2017 09:32:26 -0700] rev 34353
cleanupnodes: rename "mapping" to "replacements" The next patch will pass in overrides for bookmark moves, which is a mapping itself, so let's rename "mapping" to "replacements" to distinguish them better. Differential Revision: https://phab.mercurial-scm.org/D749
Wed, 20 Sep 2017 09:10:43 -0700 cleanupnodes: separate out bookmark destination calculation from actual update stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 20 Sep 2017 09:10:43 -0700] rev 34352
cleanupnodes: separate out bookmark destination calculation from actual update We will soon want to pass in overrides for bookmark movements and this will make that patch simpler. I also think this makes the code easier to follow regardless of the later patch. Differential Revision: https://phab.mercurial-scm.org/D748
Wed, 20 Sep 2017 09:55:52 -0700 ui: check for progress singleton when clearing progress bar (issue5684) stable
Mark Thomas <mbthomas@fb.com> [Wed, 20 Sep 2017 09:55:52 -0700] rev 34351
ui: check for progress singleton when clearing progress bar (issue5684) A combination of wrapping `ui` and progress bars interrupted by exceptions can lead to the progress bar not being cleared when the exception error is printed. This results in corrupted-looking output like this: ``` updating [===============================> ] 1/2u nresolved conflicts (see hg resolve, then hg rebase --continue) ``` This is because in `ui._progclear`, we only check the local reference to the progress bar, not whether or not there is an instance of the singleton. When a progress bar is interrupted by an exception, the exception printing in `scmutil.callcatch` uses the original instance of the `ui` object, not the wrapped copy that has `_progbar` set. When consider whether or not to clear the progress bar, check for the existence of the singleton, rather than just whether or not we have a local reference to it. Differential Revision: https://phab.mercurial-scm.org/D743
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip