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
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
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
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
py3: whitelist 15 more tests passing on Python 3
We have reached the count of 75 tests passing on Python 3.
Differential Revision: https://phab.mercurial-scm.org/D858
py3: use pycompat.bytestr instead of str
Differential Revision: https://phab.mercurial-scm.org/D855
py3: explicitly convert dict.keys() and dict.items() into a list
Differential Revision: https://phab.mercurial-scm.org/D853
py3: use '%d' instead of '%s' for integers
Differential Revision: https://phab.mercurial-scm.org/D856
py3: use pycompat.strkwargs() before passing a dict as keyword argument
Differential Revision: https://phab.mercurial-scm.org/D854
py3: return False early while checking whether None is a key in lazymanifest
In this patch we returns False early if we are trying to check whether None is a
key in lazymanifest. The reason I added a diff is that on Python 3, it goes into
the lazy manifest code an returns a TypeError. I checked with Durham that
whether None can be a possible key in lazymanifest and he said "no". So it's
safe to have this if statement.
This fixes `hg merge` on Python 3.
Differential Revision: https://phab.mercurial-scm.org/D852