merge with stable

nodes: expand/comment the magic nodes so they are more easily searchable We just encountered `000000000000modified`, and it was quite annoying to search for these, even though I knew they existed. For those that don't know that they exist, this is essentially impossible to search for :) (Technically we encountered it in its hex form, 3030303030303030303030306d6f646966696564, so I'm adding comments with those forms in case that's helpful to people in the future). Differential Revision: https://phab.mercurial-scm.org/D4331

revlog: obtain the first node at the lowest layer while building pure nodemap Just for clarity. This doesn't matter in practice since changelog.nodemap is accessed *before* filtered revisions get ready.

revlog: fix pure nodemap to not access missing index entry This bug was revealed by a3dacabd476b and a1f934573c0b.

changelog: remove copy of revlog.nodemap() It's been there since 2012, "clfilter: introduce `filteredrevs` attribute on changelog." I don't think we can apply changelog filtering to nodemap at this level, so this patch removes the nodemap stub completely.

branchmap: explicitly convert file into iterator Follows up 2a4bfbb52111. This is required for httprangereader, which is not an iterable itself.

branchmap: close cache file properly Follows up 2a4bfbb52111.

branchmap: strip '\n' read from cache file as before Follows up 2a4bfbb52111.

rebase: do not pass in user option to rollback in-memory merge conflict Nothing passed before e9e742bd0501.

rebase: add test for in-memory merge conflicts

rebase: call _dorebase() properly This fixes a regression from e9e742bd0501 where we failed to pass all necessary arguments to _dorebase(). Differential Revision: https://phab.mercurial-scm.org/D4302

context: make sure file is not deleted while checking path conflicts If a file is deleted and a directory of same name is created in the same commit, IMM thinks of that as a file conflict, however the file is deleted and hence the directory can be created. The test change demonstrate the fix. Differential Revision: https://phab.mercurial-scm.org/D4300

tests: demonstrate that IMM needs to be smarter with path conflicts When we try to rebase a commit which deletes an existing file and make a directory of the same name, rebase with IMM aborts. It should work fine just like the without IMM case. Differential Revision: https://phab.mercurial-scm.org/D4299

tests: don't create new repo inside existing repo in test-rebase-inmemory.t Differential Revision: https://phab.mercurial-scm.org/D4298

tests: remove test-py3-commands.t This was a smoke test for early in the Python 3 porting effort, before anything actually worked. Now that we've got over half the testsuite passing, this test has outlived its utility. Differential Revision: https://phab.mercurial-scm.org/D4288

tests: update test-check-py3-compat.t output in the py3exe branch This hasn't been maintained in a while, it looks like. Differential Revision: https://phab.mercurial-scm.org/D4289

overlayworkingctx: fix exception in metadata-only inmemory merges (issue5960) If there was a metadata-only mutation, such as +x or -x on a file, we would create a cache entry with None for data, and this would cause problems later on when some code tried to run fctx.data() or similar, and was expecting a string. My original fix for this involved passing data=self._wrappedctx[path].data() in setflags(), but this version seems slightly better - this way, if we ever call write() and then call setflags(), we don't destroy the data that we wrote that's in the cache. I haven't verified that other fields aren't destroyed, such as date or flags :) Differential Revision: https://phab.mercurial-scm.org/D4287

filemerge: show actual capabilities of internal merge tools This information is useful to know which internal merge tools can be applied safely on binary files and/or symlinks.

filemerge: add config knob to check capabilities of internal merge tools For historical reason, Mercurial assumes capabilities of internal merge tools as below while examining rules to decide merge tool, regardless of actual capabilities of them. =============== ====== ======== specified via binary symlinks =============== ====== ======== --tool o o HGMERGE o o merge-patterns o (*) x (*) ui.merge x (*) x (*) =============== ====== ======== This causes: - unintentional internal merge tool is chosen for binary files via merge-patterns section of configuration file - explicit configuration of internal merge tool for symlinks is ignored unintentionally But on the other hand, simple "check capability strictly" might break backward compatibility (e.g. existing merge automations), because it changes the result of merge tool selection. Therefore, this patch adds config knob "merge.strict-capability-check" to control whether capabilities of internal merge tools should be checked strictly or not. If this configuration is true, capabilities of internal merge tools are checked strictly in (*) cases above.

filemerge: show warning if chosen tool has no binary files capability While matching patterns in "merge-patterns" configuration, Mercurial silently assumes that all merge tools have binary files capability. This implementation comes from 5af5f0f9d724 (or Mercurial 1.0). At failure of merging binary files with incorrect internal merge tool, there is no hint about this silent ignorance of binary files capability. This patch shows warning message, if chosen internal merge tool has no binary files capability. This will help users to investigate why a binary file isn't merged as expected.

filemerge: add the function to examine a capability of a internal tool For "symlink" and "binary" capabilities, _toolbool() can not examine these of internal merge tools strictly, because it examines only configurations in "merge-tools" section. Users can configure them explicitly as below for example, but this is not ordinary usage and not convenient: [merge-tools] :other.symlink = true :other.binary = true This patch adds hascapability() internal function, which can examine actual capabilities of a internal merge tool strictly. At this patch, hascapability() is still used with "strict=False". Subsequent patches use it with "strict=True".

filemerge: set actual capabilities of internal merge tools This information is used to detect actual capabilities of internal merge tools by subsequent patches. For convenience, this patch assumes that merge tools typed as "nomerge" have both binary files and symlinks capabilities.

help: describe more detail about capabilities while deciding merge tool "hg help merge-tools" describes as below: (internal merge tools) will by default not handle symlinks or binary files. But in some cases, Mercurial assumes that internal merge tools have one or both of these capabilities. "hg help merge-tools" also describes as below, for matching patterns in merge-patterns configuration section. But this is not sufficient. Here, binary capabilities of the merge tool are not considered. This patch describes more detail about capabilities while deciding merge tool.

tests: un-glob patchbomb test lines that were only globbing a hostname Differential Revision: https://phab.mercurial-scm.org/D4296

tests: force a stable hostname in patchbomb tests No visible output changes in this commit because everything is globbed away, but on Python 3 the stable hostname will mean that the headers don't trigger RFC2822 multi-line mode because they'll always be consistently short. Differential Revision: https://phab.mercurial-scm.org/D4295

patchbomb: allow using HGHOSTNAME to force a hostname I'll update run-tests.py to set this globally to stabilize some tests. The variable name is intentionally generic because I suspect we should generalize this to other tests. Differential Revision: https://phab.mercurial-scm.org/D4294

patchbomb: extract function for generating message-id Differential Revision: https://phab.mercurial-scm.org/D4293

rebase: cover restorestatus() by lock to prevent it from being updated To prevent it from being updated by another process `restorestatus()` is moved under lock. Differential Revision: https://phab.mercurial-scm.org/D4282

branchmap: load branchmap as an iterable This avoids reading all the file into memory if the cache turns out to be invalid. Differential Revision: https://phab.mercurial-scm.org/D4281

perf: time loading branchmap caches Differential Revision: https://phab.mercurial-scm.org/D4280

tests: add conditional output when simplestore extensions is loaded This drops the number of failures with this extension to 3. Differential Revision: https://phab.mercurial-scm.org/D4286

tests: conditionalize extension tests for extra extensions If extra extensions are loaded (e.g. via --extra-config-opt), the tests conditionalized in this commit fail in ways that are dependent on the extensions that are loaded. So let's skip them when that scenario is present. This drops the number of failures for the simplestorerepo.py extension to 4. Differential Revision: https://phab.mercurial-scm.org/D4285

commit: try hard to reuse p1 manifest if nothing changed This is all for commit reproducibility on "hg convert". With this change, p1 manifest is reused if ctx.files() *to be committed* is empty, and if new manifest entry is identical to p1. This is important property for "hg convert" since memctx.files() built from a convert source may be either a) more narrowed thanks to a committed ctx.files() which provides more accurate status, or b) containing redundant files because of sloppy filtering on e.g. octopus merge.

merge: add tests for commit with no content change It isn't easy to say when to reuse the p1 manifest. Basically, that's only when wctx.files() is empty, but we need to know that wctx.files() is not the same as repo['.'].files() after the commit. This patch adds several examples of commits with empty ctx/wctx.files(). I don't think this is exhaustive, but it contains at least one failure mode in which a converted repo result in a different hash. I also note that the manifest revlog does NOT follow the DAG shape of the changelog since p1 manifest is reused if wctx.files() is empty even at merge. I don't know whether it is intentional or not, but it's the behavior since 2011, 301725c3df9a "localrepo: reuse parent manifest in commitctx if no files have changed."

commit: add debug message regarding manifest reuse

mail: convert encoding.encoding to sysstr

mail: call s.decode('ascii') explicitly to see if s is an ascii bytes

mail: pass in addr to _addressencode() in bytes _addressencode() doesn't process a unicode addr well. For example, acc.encode('ascii') would raise UnicodeEncodeError if acc was a unicode. This patch temporarily restores the pre-952bf3c948f0 _addressencode(). Several tests would be broken on Python 3.

mail: remove redundant bytesurl() from addrlistencode() _addressencode() returns a bytes.

patchbomb: really use BytesGenerator API It wraps around Generator type.

byteify-strings: prevent "__name__ == '__main__'" from being transformed This was okay for import-time code transformer, but shouldn't be applied to source code.

merge with stable

rebase: turn off inmemory flag on --stop Guessing from the inline comment, "in-memory rebase is not compatible with resuming rebases", in-memory rebasing should be disabled.

rebase: use action variable to select things to do

rebase: consolidate check for --dry-run/--confirm on abort/stop/continue

rebase: consolidate check for --abort/--stop/--continue conflicts

rebase: do not set internal dryrun flag by --confirm This prepares for cleaning up option checking.

rebase: add test to show --stop moves bookmarks Added tests to show that --stop option moves bookmarks of rebased csets to their succs. Differential Revision: https://phab.mercurial-scm.org/D3982

rebase: include --stop option in documentation Differential Revision: https://phab.mercurial-scm.org/D3970

rebase: raise error for options conflicting with --stop Make sure --stop feature raise error for conflicting options --continue, --abort, --confirm, --dry-run. Tests are added to reflect the same. Differential Revision: https://phab.mercurial-scm.org/D3969

rebase: add --stop option to stop rebase at any point (issue5206) Before this patch, during a rebase if you get a point where you can't figure out what to do next, then either you had to complete your series or abandon all the work you have done during this rebase. Now, with this feature you can stop at any point by keeping the rebased csets and mark original csets as obsolete. And if you don't have evolution extension enabled then you can use --keep option as an alternative which will keep original csets too, instead of marking them obsolete. Differential Revision: https://phab.mercurial-scm.org/D3959

statprof: cleanup string construction Use string substitutions instead of string additions.

addremove: add associated color for the new labels We use classic color: green is added, red is removed.

remove: add a label for messages about removed files Keeping consistency between addremove and remove seems a good idea.

add: add a label for messages about added files Keeping consistency between addremove and add seems a good idea.

addremove: add labels for messages about added and removed files This is the first step to add color for add and remove output.

revlog: filter out "invalid" delta base candidates There are bases that we know won't produce a good delta chain. For example, if the base is already bigger than twice the size of the text we store, we know the resulting delta chain will never be valid. We might make the check a bit more powerful and generic in the future, but this looks a good start. In particular, empty file (size 0) will never find a good base, so we should stop spending time trying to find one.

revlog: use a symbolic constant for the deltas/text ration We are about to use it somewhere else, we should as well make it easier to access and change.

revlog: do not search for delta for empty content We won't find any useful base to store an empty text. So we should not even try to.

revlog: split and document good delta conditional The logic is still identical, but having each conditional on its own helps to document them and will help to edit them in the future.

revlog: skip over empty revision when looking for delta base There is no point in keeping an empty revision in the middle of a chain since they won't contribute any data. So we filter them out when looking for a valid base delta.

debugrevlog: display details about empty revision We now display details about the course of emptiness (empty text or empty delta).

debugrevlog: track empty revlog entries A revlog entry can be "empty" for two reasons: * the stored text is empty * we found another entry with the exact same content Tracking them separately make revlog content clearer.

debugrevlog: document some of the variable used This help to understand the code.