Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 20 Mar 2019 20:42:10 +0300] rev 41990
tests: glob seconds in test-upgrade-repo.t
I had the test failing locally for me with diff showing `1.4s` instead of 0.0s
Differential Revision: https://phab.mercurial-scm.org/D6161
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 20 Mar 2019 20:39:44 +0300] rev 41989
store: recommend using `hg debugrebuildfncache` is fncache is corrupted
Differential Revision: https://phab.mercurial-scm.org/D6160
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 14:48:49 +0300] rev 41988
debugsparse: abort if the repository is not sparse instead of ui.status()
This is similar to what narrow extension does.
Differential Revision: https://phab.mercurial-scm.org/D6149
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Mar 2019 14:17:41 -0700] rev 41987
revert: option to choose what to keep, not what to discard
I know the you (the reader) are probably tired of discussing how `hg
revert -i -r .` should behave and so am I. And I know I'm one of the
people who argued that showing the diff from the working copy to the
parent was confusing. I think it is less confusing now that we show
the diff from the parent to the working copy, but I still find it
confusing. I think showing the diff of hunks to keep might make it
easier to understand. So that's what this patch provides an option
for.
One argument doing it this way is that most people seem to find `hg
split` natural. I suspect that is because it shows the forward diff
(from parent commit to the commit) and asks you what to put in the
first commit. I think the new "keep" mode for revert (this patch)
matches that.
In "keep" mode, all the changes are still selected by default. That
means that `hg revert -i` followed by 'A' (keep all) (or 'c' in
curses) will be different from `hg revert -a`. That's mostly because
that was simplest. It can also be argued that it's safest. But it can
also be argued that it should be consistent with `hg revert -a`.
Note that in this mode, you can edit the hunks and it will do what you
expect (e.g. add new lines to your file if you added a new lines when
editing). The test case shows that that works.
Differential Revision: https://phab.mercurial-scm.org/D6125
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Mar 2019 14:58:35 -0700] rev 41986
patch: include newline at EOF in help text for interactive patch
The lack of a newline means that some "editors" that are useful in
tests, such as `echo "+new line" >> "$1"` don't work. It's obviously
easy to work around it, but newline at EOF seems like a good practice
anyway.
Differential Revision: https://phab.mercurial-scm.org/D6124
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 19 Mar 2019 16:36:59 +0300] rev 41985
merge with stable