- Jun 01, 2020
-
-
Manuel Jacob authored
If the config rewrite.empty-successor=skip is set, a message "became empty and was dropped" is shown if the changeset became empty. If the config rewrite.empty-successor=keep is set, absorb may create changesets even if they became empty. It’s probably a good idea to make that explicit. Therefore the message is changed to be a combination of both: "became empty and became ...". Repeating the word "became" is not very elegant. This results from the fact that "became" was and is overloaded to indicate both the change from non-empty to empty and the successor relation. In the combinated message, both meanings are used in one sentence.
-
Manuel Jacob authored
This adds support for the recently added rewrite.empty-successor configuration.
-
Manuel Jacob authored
This adds support for the recently added rewrite.empty-successor configuration.
-
- Jul 12, 2020
-
-
Manuel Jacob authored
-
- Jul 11, 2020
-
-
Manuel Jacob authored
The default for many history-rewriting commands (e.g. rebase and absorb) is that changesets which would become empty are not created in the target branch. This makes sense if the source branch consists of small fix-up changes. For more advanced workflows that make heavy use of history-editing to create curated patch series, dropping empty changesets is not as important or even undesirable. Some users want to keep the meta-history, e.g. to make finding comments in a code review tool easier or to avoid that divergent bookmarks are created. For that, obsmarkers from the (to-be) empty changeset to the changeset(s) that already made the changes should be added. If a to-be empty changeset is pruned without a successor, adding the obsmarkers is hard because the changeset has to be found within the hidden part of the history. If rebasing in TortoiseHg, it’s easy to miss the fact that the to-be empty changeset was pruned. An empty changeset will function as a reminder that obsmarkers should be added. Martin von Zweigbergk mentioned another advantage. Stripping the successor will de-obsolete the predecessor. If no (empty) successor is created, this won’t be possible. In the future, we may want to consider other behaviors, like e.g. creating the empty successor, but pruning it right away. Therefore this configuration accepts 'skip' and 'keep' instead of being a boolean configuration.
-
- Aug 31, 2019
-
-
Pierre-Yves David authored
Small cleanup for future when we have an option to show configs from shared rc. Differential Revision: https://phab.mercurial-scm.org/D8658
-
- Jul 06, 2020
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D8684
-
Jörg Sonnenberger authored
In the manifest line, flags are put directly after the hash, so the parser has been guessing the presence of flags based on the length of the hash. Replace this assumption by an enumeration of the valid flags and removing them from the hash first as they are distinct input values. Consistently handle the expected 256bit length of the SHA1-replacement in the pure Python parser. Check that setting flags will use one of the blessed values. Extend write logic in the C version to handle 256bit hashes as well. Verify that hashes always have exactly the expected length. Since 1070df141718 we should no longer depend on the old extra-byte hack. Differential Revision: https://phab.mercurial-scm.org/D8679
-
- Jul 07, 2020
-
-
Jörg Sonnenberger authored
When the internal and archived phase was added, allphase became a large, sparsely populated list. This dramatically increased the number of lookup operations for public relations in `phasecache.phase`. As a first step, define allphases and related lists explicitly to contain only the actual phases. Make phasenames a dictionary and create corresponding dictionaries for mapping phase names back to numbers. Adjust various list to be sparse as well with the exception of phaseroots and phasesets members of phasecache. Keep those as a separate step as it involves changes to the C module. Differential Revision: https://phab.mercurial-scm.org/D8697
-
Jörg Sonnenberger authored
Historically, updatephases used to skip the secret phase, but wasn't updated when archived and internal were added. Differential Revision: https://phab.mercurial-scm.org/D8696
-
- Jun 27, 2020
-
-
Jörg Sonnenberger authored
This speeds up no-change updates from 1.3s to 0.85s for my NetBSD test repository. Differential Revision: https://phab.mercurial-scm.org/D8670
-
- Jul 07, 2020
-
-
Jörg Sonnenberger authored
This decouples users from the implementation details of the phasecache. Also document a historic artifact about the stored phaseroots. Differential Revision: https://phab.mercurial-scm.org/D8694
-
- Jun 24, 2020
-
-
Raphaël Gomès authored
This is 3/3 in a series of patches to improve dirstate status' code. Following in the footsteps of a46e36b82461, we move the main status functionality to an `Operation`. This will most likely be subject to change in the future (what function signature, what parameters, etc., but we will see when `rhg` gets `hg status` support. Differential Revision: https://phab.mercurial-scm.org/D8663
-
Raphaël Gomès authored
This patch is 2/3 in the series to improve the dirstate status code. It adds a number of common type aliases to add more obvious semantics to function signatures, improves/adds documentation where necessary and improves one or two patterns to be more idiomatic. Differential Revision: https://phab.mercurial-scm.org/D8662
-
Raphaël Gomès authored
The code for `dirstate/status` has grown too large for comfort, this is the first of three patches that try to improve maintainability. In this patch, refactoring dirstate's status into a struct allows for slimming down function signatures drastically, keeping the mental (and maintenance) burden lower, since pretty much all of them shared a few common arguments. This had the pleasant side-effect of simplifying lifetimes a little. This has no observable impact on performance. The next patch will add/improve documentation and refactor some types. I tried to keep new code down to a minimum in this patch because it's already pretty big. Differential Revision: https://phab.mercurial-scm.org/D8661
-
- Dec 14, 2019
-
-
Martin von Zweigbergk authored
This helps with readability. Differential Revision: https://phab.mercurial-scm.org/D8735
-
Martin von Zweigbergk authored
This helps with readability. Differential Revision: https://phab.mercurial-scm.org/D8734
-
- Jun 22, 2020
-
-
Pulkit Goyal authored
If we have multiple cases in a test, that leads us to a temp path of format "<temp-path>-<case1>#<case2>". This leads to hg.parseurl() parsing the path and take part after `#` as a branch name. I encountered this bug while adding support for share-safe case in next patch. Differential Revision: https://phab.mercurial-scm.org/D8647
-
- Apr 14, 2020
-
-
Pulkit Goyal authored
This for now just prints out the list of current requirements. In future this will be helpful in reading requirements from couple of sources, and checking which requirement comes from where. Differential Revision: https://phab.mercurial-scm.org/D8632
-
Pulkit Goyal authored
In upcoming patches, to implement Share Safe plan we will be introducing requires file in store. We need to route all callers to a single function to check for a share-safe requirement and if present, write requirements to .hg/store/requires instead. After this patch, callers directly calling scmutil.writerequires() are only those where we don't have the repo object, for example when initializing the repository object itself. Differential Revision: https://phab.mercurial-scm.org/D8631
-
- Jul 14, 2020
-
-
Martin von Zweigbergk authored
When running `hg nonexistent`, we try to look for extensions that provide that command. We do that by looking for files in the `hgext.__file__` directory. However, PyOxidizer doesn't provide a `__file__`, so we crash when running with PyOxidizer. We should be able to look for the command in built-in extensions, but we seem to already have code for skipping the scan when running in a frozen binary, so I just modified that code instead. By the way, it also seems like we should be able to search for extensions in the `hgext3rd` module, but we don't do that yet either (before or after this patch). Differential Revision: https://phab.mercurial-scm.org/D8750
-
- Jul 09, 2020
-
-
Manuel Jacob authored
In the previous version, I used tempfile.mktemp() because it seemed to be the only way to open a file from two processes (the Python documentation says the file backing NamedTemporaryFile can’t be opened a second time on Windows). However, it’s possible when passing the O_TEMPORARY flag to the second open. Source: https://stackoverflow.com/a/15235559/6366251
-
- Jul 15, 2020
-
-
Manuel Jacob authored
Because this function isn’t meant for general use (e.g., it’s Python 2-only), make in a module-private function by prefixing it with `_`.
-
- Jul 13, 2020
-
-
Yuya Nishihara authored
User can press Ctrl+C while flushing streams in dispatch.run(). In such case, I think exiting with 255 is better than printing Python traceback and exiting with 1.
-
Yuya Nishihara authored
I'll add KeyboardInterrupt handling there.
-
- Jul 09, 2020
-
-
Yuya Nishihara authored
While Microsoft trained us to read mojibake text, it doesn't make sense to print mojibake messages when debugging the exact issue.
-
- Jul 15, 2020
-
-
Augie Fackler authored
-
- Jul 06, 2020
-
-
Pulkit Goyal authored
Right now extdiff uses it's own logic using archival to diff two versions of file using external diff tools. This makes the extdiff functionality non-extensible. This series is an attempt to refactor core patch and diff functionality so that extdiff can wrap and reuse it. This will help us in using external diffing tools at more places and not just extdiff command only then. Differential Revision: https://phab.mercurial-scm.org/D8685
-
- Jul 09, 2020
-
-
Manuel Jacob authored
On Windows, we currently don’t fully test the case when the stream is connected to a TTY, but we test the child process side by connecting them to NUL, which is recognized as a TTY by Python. To make the large write test a bit more useful besides checking that it doesn’t crash, we can check that the write() method returns the correct result.
-
Manuel Jacob authored
The original motivation was that creating PTYs on Windows is not possible, but `NUL` is recognized as a TTY, so we can have at least some test coverage for the TTY case. I think it doesn’t hurt to run the test cases on all systems.
-
- Jul 10, 2020
-
-
Manuel Jacob authored
Python 3 offers different kind of streams and it’s not guaranteed for all of them that calling write() writes all bytes. When Python is started in unbuffered mode, sys.std{out,err}.buffer are instances of io.FileIO, whose write() can write less bytes for platform-specific reasons (e.g. Linux has a 0x7ffff000 bytes maximum and could write less if interrupted by a signal; when writing to Windows consoles, it’s limited to 32767 bytes to avoid the "not enough space" error). This can lead to silent loss of data, both when using sys.std{out,err}.buffer (which may in fact not be a buffered stream) and when using the text streams sys.std{out,err} (I’ve created a CPython bug report for that: https://bugs.python.org/issue41221). Python may fix the problem at some point. For now, we implement our own wrapper for procutil.std{out,err} that calls the raw stream’s write() method until all bytes have been written. We don’t use sys.std{out,err} for larger writes, so I think it’s not worth the effort to patch them.
-
- Jul 11, 2020
-
-
Manuel Jacob authored
This should probably be part of the previous patch, but folding it results in a less useful word diff, so I decided to keep it separate for review.
-
- Jul 10, 2020
-
-
Manuel Jacob authored
It makes sense to have the distinction between Python 2 and 3 at the top level, as we have to fight a different kind of battle on each: On Python 3, we get consistent behavior on all platforms, but need to create correctly-behaving binary streams. On Python 2, we have to account for platform differences.
-
- Jul 14, 2020
-
-
Manuel Jacob authored
The keys and values of the extra dict are expected to be bytes. Before this fix, there was a crash in mercurial.changelog.encodeextra().
-
- Jul 11, 2020
-
-
Manuel Jacob authored
Differential Revision: https://phab.mercurial-scm.org/D8733
-
Manuel Jacob authored
The new code has a small overhead in the empty commit case, as a `memctx` object is always created, but I don’t think it’s justified here to duplicate code to optimize a relatively unlikely code path. Differential Revision: https://phab.mercurial-scm.org/D8732
-
Manuel Jacob authored
It is part of the contract of `parents()` that non-merges return a list of one element. `self._parents` is always a list of two elements in `memctx`. Differential Revision: https://phab.mercurial-scm.org/D8731
-
- Jul 10, 2020
-
-
Manuel Jacob authored
This enables reuse in other places, e.g. those dealing with `memctx`. Differential Revision: https://phab.mercurial-scm.org/D8729
-
Manuel Jacob authored
This method is only about whether there are file changes, not about whether the commit will be empty or not. One user of the method was incorrectly assuming the latter meaning, leading to the bug for which a test case was added in D8727. I’ve added a FIXME to the code. The original motivation for the rename was that I want to add `committablectx.isempty()`, that properly checks if a commit will be empty, using the exact same logic as in `repo.commit()`, and I wanted to avoid a name clash. Differential Revision: https://phab.mercurial-scm.org/D8728
-
- Jul 09, 2020
-
-
Manuel Jacob authored
Differential Revision: https://phab.mercurial-scm.org/D8727
-