Mercurial: Changelog

extdiff: add comments and minor variable renames diffpatch() Some variable names were now confusing as we refactored the code in a separate function. For example, `node1a` leads to ideas why `1a` and not `1`. The variable storing path to patch file was named as `dirX` instead of `fileX`. Renamed these variables and added couple of comments. Differential Revision: https://phab.mercurial-scm.org/D8689

extdiff: remove unrequired do3way argument to diffpatch() When we are diffing patches, there is no 3 way diff. Differential Revision: https://phab.mercurial-scm.org/D8688

extdiff: refactor logic to diff revs of versions of files Now that code for both cases, diffing patches or files is in separate function, it will be better to refactor them more and understand. Differential Revision: https://phab.mercurial-scm.org/D8687

extdiff: refactor logic which does diff of patches The current extdiff code is hard to understand on first look. Took me few hours to grasp the code. Before adding more things, decided to do some refactoring. Differential Revision: https://phab.mercurial-scm.org/D8686

absorb: make it explicit if empty changeset was created 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.

absorb: consider rewrite.empty-successor configuration This adds support for the recently added rewrite.empty-successor configuration.

rebase: consider rewrite.empty-successor configuration This adds support for the recently added rewrite.empty-successor configuration.

rewriteutil: add utility to check whether empty successors should be skipped

config: add option to control creation of empty successors during rewrite 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.