- Sep 08, 2019
-
-
Pierre-Yves David authored
Before that, applying multiple changegroups in the same transaction issued the message multiple time. This result in a confusing output: adding changesets adding manifests adding file changes added 32768 changesets with 60829 changes to 2668 files adding changesets adding manifests adding file changes added 8192 changesets with 16885 changes to 1553 files adding changesets adding manifests adding file changes added 1020 changesets with 1799 changes to 536 files adding changesets adding manifests ... Instead, we now only issue the message once at the end of the transaction, summing up all added changesets, changes and files. The line is identical, but happens sightly later in the output. There are other suboptimal behavior around issue multiple changegroup (eg: progress bar). We'll cover them later. This impact of lot of test as one would expect, but a two pass check show they are just the order change we expected. To deal with "under the hood" bundle application by internal code, we had to take a slightly hacky move. We could clean that up with a more official way to enter "under the hood" section, however I want to keep this series simple to get it landed. This kind of change have a very high bit rot rate since it impact a lot of test output.
-
- Sep 07, 2019
-
-
Pierre-Yves David authored
I am not sure why this is not working as expected, but without this client might not see some important output. Without this patch moving some output at transaction closing time makes it disapear for ssh client in various sitaution.
-
Pierre-Yves David authored
The `quiet` approach is what `shelve` uses and give the same result. This will help us to add less code in future changesets.
-
- Oct 14, 2018
-
-
Pierre-Yves David authored
Instead of making bundle2 code responsible for this, it seems better to have it handled and the transaction level. First, it means the message will be more consistently printed. Second it means we won't spam the message over and over if the data arrive in multiple piece. Third, we are planning to move other similar message at the same level (for the same reason) so having them all at the same location will help us to control the order they are displayed.
-
Pierre-Yves David authored
We are going to improve the way this message is issued in the core codebase. This will make it appears for `hg debugobsolete` too. Since this seems like a good idea, we make the output change in a previous changesets to clarify the next changeset.
-
- Sep 05, 2019
-
-
Yuya Nishihara authored
-
- Sep 08, 2019
-
-
Yuya Nishihara authored
-
Yuya Nishihara authored
It's the implementation detail of the py_shared_iterator that the leaked reference is kept in Option<_> so that it can be dropped early.
-
Yuya Nishihara authored
It's a public interface now.
-
Yuya Nishihara authored
See the previous commit for why. The docstring is moved accordingly.
-
Yuya Nishihara authored
We wouldn't care the cost of the dynamic dispatch, but I feel a concrete type helps understanding error messages.
-
Yuya Nishihara authored
They will be used in the declaration of Python iterator types.
-
Yuya Nishihara authored
This allows us to put a returned iterator in a struct. We could implement DirsMultisetIter(hash_map::Keys<..>) struct to hide the implementation detail, but I think type alias is good enough for us.
-
- Apr 27, 2019
-
-
Pierre-Yves David authored
When using `hg push --rev X`, the subset considered by discovery is only `::X`. In addition, `X` can be any local revisions not just local heads. As a result the message "all local heads known locally" can be misleading. We replace it with the more accurate "all local changesets known remotely". The message appears when in verbose not, so this is stricly speaking a BC breakage. I am not sure this would be a real issue in practice...
-
- Sep 05, 2019
-
-
Martin von Zweigbergk authored
I recently added the bad call, thinking that findexe() was a standard library function returning a string result, but it's actually our own function returning bytes. Thanks to Yuya for noticing. Differential Revision: https://phab.mercurial-scm.org/D6826
-
- Sep 07, 2019
-
-
Pierre-Yves David authored
'raw' is really a third mode, not a small variant. Differential Revision: https://phab.mercurial-scm.org/D6807
-
Pierre-Yves David authored
People should use the specialized version instead now. Differential Revision: https://phab.mercurial-scm.org/D6806
-
- Sep 02, 2019
-
-
Pierre-Yves David authored
We now use the specialized versions. Differential Revision: https://phab.mercurial-scm.org/D6805
-
Pierre-Yves David authored
We now use the specialized versions. Differential Revision: https://phab.mercurial-scm.org/D6804
-
- Aug 30, 2019
-
-
Pierre-Yves David authored
When there are no ambiguity regarding the `raw` value, we can simply use the new method. Differential Revision: https://phab.mercurial-scm.org/D6803
-
Pierre-Yves David authored
When there are no ambiguity regarding the `raw` value, we can simply use the new method. Differential Revision: https://phab.mercurial-scm.org/D6802
-
Pierre-Yves David authored
There are no ambiguity for 'write' operation so it is simple to replace. Differential Revision: https://phab.mercurial-scm.org/D6801
-
Pierre-Yves David authored
This make the call site clearer and the open the way to more diverse return types. For now, the same old code is still in use under the hood. Differential Revision: https://phab.mercurial-scm.org/D6800
-
- Aug 08, 2019
-
-
Pierre-Yves David authored
This remove the other code duplication of the `_processflags` code. To be honest, this code looks very dead since it is not run by either developer nor buildbot. However, we update the code to make the task of reviving this less daunting. Differential Revision: https://phab.mercurial-scm.org/D6799
-
- Aug 07, 2019
-
-
Pierre-Yves David authored
One of the code duplication use a different error class. So let's make it possible to do so. Differential Revision: https://phab.mercurial-scm.org/D6798
-
- Sep 07, 2019
-
-
Pierre-Yves David authored
This remove one of the code duplication. Hooray \o/. Differential Revision: https://phab.mercurial-scm.org/D6797
-
- Aug 07, 2019
-
-
Pierre-Yves David authored
To avoid code duplication, we will provide a simple "ready to use" mixin that carry the appropriate logic. First we use it in standard revlog, we'll remove code duplication in later changesets. Differential Revision: https://phab.mercurial-scm.org/D6796
-
- Sep 07, 2019
-
-
Martin von Zweigbergk authored
Both `command` and $(command) are specified by POSIX. The latter nests better. I don't see why we shouldn't allow both (or only the latter). Differential Revision: https://phab.mercurial-scm.org/D6789
-
- Jun 14, 2019
-
-
Pierre-Yves David authored
This is clearer and more in line with some other variable names. (This is a gratuitous cleanup that I made while investigating a bug).
-
Pierre-Yves David authored
This is clearer and more in line with some other variable names. (This is a gratuitous cleanup that I made while investigating a bug).
-
Pierre-Yves David authored
More explicit variable name never hurt. (This is a gratuitous cleanup that I made while investigating a bug).
-
Pierre-Yves David authored
(This is a gratuitous cleanup that I made while investigating a bug).
-
- Aug 26, 2019
-
-
sliquister authored
Differential Revision: https://phab.mercurial-scm.org/D6765
-
sliquister authored
For legibility of the resulting regexes, although it may help with performance as well. Differential Revision: https://phab.mercurial-scm.org/D6764
-
sliquister authored
Differential Revision: https://phab.mercurial-scm.org/D6766
-
sliquister authored
Differential Revision: https://phab.mercurial-scm.org/D6763
-
- Jul 17, 2019
-
-
Martin von Zweigbergk authored
When amending a changeset with copy information in the changeset and the new changeset doesn't have any copy information (or similar for "filesadded" and "filesremoved"), we shouldn't keep it. A drawback of this is that we now unconditionally remove these four entries from the extras, breaking any extensions that happened to write entries with the same names (which seems very unlikely). I think I'd heard that there was list of blacklisted keys that would be removed from the extras when a commit is rewritten, but I couldn't find that. It would make sense to add the keys mentioned above there instead of the custom filtering I've added in this patch. Differential Revision: https://phab.mercurial-scm.org/D6752
-
Martin von Zweigbergk authored
If you turn on copies in changesets and write a commit with a copy, then turn it off and amend the commit while undoing the copy, the invalid copy information will remain. The read path doesn't crash in invalid copy data, but it seems better to not produce the invalid data. Differential Revision: https://phab.mercurial-scm.org/D6751
-
- Aug 19, 2019
-
-
Martin von Zweigbergk authored
workingctx normally gets its lists of modified, added, removed files etc. based on the dirstate status. Its constructor also accepts a "changes" argument to override the status from the dirstate. This is used for partial commits. If a "changed" argument was passed, we should clearly also filter out copies to those paths, which I had previously missed. This patch adds that filtering and fixes the bugs demonstrated in the previous patch. Differential Revision: https://phab.mercurial-scm.org/D6750
-
Martin von Zweigbergk authored
When writing copy metadata to the changeset and not committing all copies in the dirstate, we get a ProgrammingError. This commit adds two tests showing how to trigger this bug. Differential Revision: https://phab.mercurial-scm.org/D6749
-