overlayworkingctx: fix a bad reference to `self._path` Differential Revision: https://phab.mercurial-scm.org/D1236

overlayworkingctx: track copy information in the context We can no longer do so in the dirstate, so add the functions to do so here. Differential Revision: https://phab.mercurial-scm.org/D1235

rebaseruntime: raise InMemoryMergeConflictsError on merge conflicts Differential Revision: https://phab.mercurial-scm.org/D1234

rebase: do not bail on uncomitted changes if rebasing in-memory Differential Revision: https://phab.mercurial-scm.org/D1233

rebase: add the --inmemory option flag; assign a wctx object for the rebase In the future, the --inmemory flag might be deprecated in favor of something more intelligent (for example, always rebasing in-memory if the working copy parent isn't in the rebaseset). But we might keep it as a way to explicitly force IMM on or off. Differential Revision: https://phab.mercurial-scm.org/D1232

overlayworkingctx: move _wrappedctx out of the constructor With rebase, we will be setting the _wrappedctx at a different point from the wctx construction (somewhat later, and possibly several times). Move it to a public function. Differential Revision: https://phab.mercurial-scm.org/D1231

merge: don't check for unknown files in IMM Differential Revision: https://phab.mercurial-scm.org/D1214

rebase: enable multidest by default This was intended to be done by D470. But there was a minor documentation issue. The feature is quite usable now so it gets formally documented and enabled. There is no behavior change for people not using the `SRC` or `ALLSRC` in rebase destination revset. .. feature:: Rebase with different destination per source revision Previously, rebase only supports one unique destination. Now ``SRC`` and ``ALLSRC`` can be used in rebase destination revset to precisely define destination per each individual source revision. For example, the following command could move some orphaned changesets to reasonable new places so they become no longer orphaned:: hg rebase -r 'orphan()-obsolete()' -d 'max((successors(max(roots(ALLSRC) & ::SRC)^)-obsolete())::)' Differential Revision: https://phab.mercurial-scm.org/D1063

overlayworkingctx: make clean() public It will be called directly by rebase after concluding a node. Differential Revision: https://phab.mercurial-scm.org/D1230

overlayworkingctx: remove flushall() Differential Revision: https://phab.mercurial-scm.org/D1216

merge: skip subrepo state, update hooks, and updating the dirstate in IMM Differential Revision: https://phab.mercurial-scm.org/D1215

merge: remove calls to flushall() Since D1105, these are unnecessary since IMM will now never use workers. Differential Revision: https://phab.mercurial-scm.org/D1213

filemerge: raise InMemoryMergeConflictsError if we hit merge conflicts in IMM Merge conflicts might be supported in the future, but for now are kept out of scope. Any places where we used to call `flushall()` should be replaced with some kind of exception. At this point, IMM M1 is no longer supported. Differential Revision: https://phab.mercurial-scm.org/D1212

context: switch ctx() use to changectx() I added `ctx()` to `overlayworkingfilectx`, (and before that, `absentfilectx`), because `absentfilectx` had reference to this function in its `cmp()` function. But the standard is actually `changectx()`, and no other class implements `ctx()`. So let's use the standard name. (As a result, I'm not sure that part of the `absentfilectx` comparator ever worked! It was written before I added either function.) This will be necessary in the next patch. Differential Revision: https://phab.mercurial-scm.org/D1211

lfs: introduce a user level cache for lfs files This is the same mechanism in place for largefiles, and solves several problems working with multiple local repositories. The existing largefiles method is reused in place, because I suspect that there are other functions that can be shared. If we wait a bit to identify more before `hg cp lfutil.py ...`, the history will be easier to trace. The push between repo14 and repo15 in test-lfs.t arguably shouldn't be uploading any files with a local push. Maybe we can revisit that when `hg push` without 'lfs.url' can upload files to the push destination. Then it would be consistent for blobs in a local push to be linked to the local destination's cache. The cache property is added to run-tests.py, the same as the largefiles property, so that test generated files don't pollute the real location. Having files available locally broke a couple existing lfs-test-server tests, so the cache is cleared in a few places to force file download.

largefiles: refactor _usercachedir() to allow reuse with lfs Largefiles puts everything into a flat directory, while lfs divides files up by creating subdirectories consisting of the first two characters of the hash. Therefore, pointing at the largefiles cache won't work.

lfs-test: note a problem with unpushed lfs files and cloning/sharing AFAIK, this isn't an issue with largefiles because it knows how to look in the system-wide cache.

patch: add within-line color diff capacity The `diff' command usually writes deletion in red and insertions in green. This patch adds within-line colors, to highlight which part of the lines differ. Lines to compare are decided based on their similarity ratio, as computed by difflib SequenceMatcher, with an arbitrary threshold (0.7) to decide at which point two lines are considered entirely different (therefore no inline-diff required). The current implementation is kept behind an experimental flag in order to test the effect on performance. In order to activate it, set inline-color-diff to true in [experimental].

dagop: extend filectxancestors() to walk multiple files

dagop: put start fctx into visit dict of filectxancestors() Prepares for multiple start revisions/files.

dagop: change visit dict of filectxancestors() indexed solely by rev In future patches, a max heap will be used to compute the next revision to visit.

dagop: use fctx.rev() consistently in filectxancestors() We can't use fctx.linkrev() to sort fctxs coming from multiple files. This was changed at 24b57c3899f8 due to performance issue, but we know we evaluate parent.rev() in revset anyway.

dagop: yield intro filectx by filectxancestors() This is the convention of dagop.*ancestors() functions.

filectx: extract helper method to obtain filectx pointing to its introrev

dagop: copy basefilectx.ancestors() to free function The primary goal of this series is to make follow() support multiple start revisions. dagop.filectxancestors() will be extended to take multiple filectxs. basefilectx.ancestors() is not forwarded to this function because doing that would resurrect the performance issue fixed by 24b57c3899f8.

test-log: test that fctx.ancestors() can't index parents only by linkrev This covers a possible bug that could be caused by the following change: --- a/mercurial/context.py +++ b/mercurial/context.py @@ -1047,7 +1047,7 @@ class basefilectx(object): while True: for parent in c.parents()[:cut]: - visit[(parent.linkrev(), parent.filenode())] = parent + visit[parent.linkrev()] = parent if not visit: break c = visit.pop(max(visit))

pull: retrieve bookmarks through the binary part when possible This makes pull consistent with the part used by push and provide us with a more compact representation of bookmarks. In addition, this opens the way for smarter bookmark exchanges (e.g. filtering by names or only sending the bookmark relevant to the pulled set, etc).

getbundle: add support for 'bookmarks' boolean argument This new argument requests a 'bookmarks' part from the server. It is meant to be used instead of the "listkeys" request.

bundle2: support a 'records' mode for the 'bookmarks' part In this mode, the bookmarks changes are record in the 'bundleoperation' records instead of inflicted to the repository. This is necessary to use the part when pulling.

bundle2: add a 'modes' dictionary to the bundle operation This new attribute allows the codes requesting an unbundling to pass important information to individual part handlers. The current target use case is to allow for receiving 'bookmarks' part without directly updating local repository, but just recording the received data instead. This is necessary for pull where the remote bookmarks are processed locally. I expect the concept to be beneficial to other parts in the future. To clarify the bookmark behavior on pull, the remote bookmark value are not just taken -as-is- into the local repository. There is an extra step to detect bookmark divergence. The remote bookmarks data are stored until this processing happens.