rebase: backout changeset d755a9531fce This is a dependency for a future backout of 88fde8db5307. See the previous patches for why.

rebase: backout changeset 986d04b9fedd This is a dependency for a future backout of 88fde8db5307. See the previous patches for why.

graft: don't preserve most extra fields This backs out changeset 804abe8999f3. See the previous patch for why we're doing this.

amend: don't preserve most extra fields This backs out changeset 39163708825cd. There are some extra fields that absolutely should not be preserved, like the convert_revision field introduced by the convert and hgsubversion extensions. The problem with extensions blacklisting certain extra fields is that they might not be enabled at the time the amend is performed. In the long run we probably want separately marked transferable and non-transferable extra fields, but for now restore the old Mercurial 3.6 behavior.

histedit: fix typo in documentation

osutil: do not abort loading pure module just because libc has no recvmsg() On Solaris, recvmsg() is provided by libsocket.so. We could try hard to look for the library which provides 'recvmsg' symbol, but it would make little sense now since recvfds() won't work anyway on Solaris. So this patch just disables _recvmsg() on such platforms. Thanks to FUJIWARA Katsunori for spotting this problem.

osutil: disable compilation of recvfds() on unsupported platforms It appears that Solaris doesn't provide CMSG_LEN(), msg_control, etc. As recvfds() is only necessary for chg, this patch just drops it if CMSG_LEN isn't defined, which is the same workaround as Python 3.x. https://hg.python.org/cpython/rev/c64216addd7f#l7.33

i18n-pt_BR: synchronized with 0ec12435b78b

merge with stable

Added signature for changeset 2408645de650

Added tag 3.7 for changeset 2408645de650

merge with i18n

verify: recover lost freeing of memory In df8973e1fb45 (verify: move file cross checking to its own function, 2016-01-05), "mflinkrevs = None" was moved into function, so the reference was cleared there, but the calling function now held on to the variable. The point of clearing it was presumably to free up memory, so let's move the clearing to the calling function where it makes a difference. Also change "mflinkrevs = None" to "del mflinkrevs", since the comment about scope now surely is obsolete.

rebase: better way to detect non-detaching revisions (issue5044) Rather than look for the lowest revision, see if the rebase state is tracking the parents of this revision. Otherwise we can't handle multiple revisions in one rebase that includes a merge revision. Fixes issue5044.

i18n-ja: synchronized with 88609cfa3745

i18n-pt_BR: synchronized with f0d3c5794380

doc: itemize text blocks to increase readability in HTML format Before this patch, text blocks changed in this patch are shown as just continuous text blocks like below in HTML format. Global configuration like the username setting is typically put into: %USERPROFILE%\mercurial.ini $HOME/.hgrc This patch itemizes these text blocks to increase readability in HTML format. Global configuration like the username setting is typically put into: - %USERPROFILE%\mercurial.ini (on Windows) - $HOME/.hgrc (on Unix, Plan9) Like as other platform sensitive container-ed text blocks, this patch also adds explicit "on PLATFORM" information to each items for readability in HTML format, even though output of "hg help config" on command line seems a little redundant. For example, on Unix: Global configuration like the username setting is typically put into: - "$HOME/.hgrc" (on Unix, Plan9)

doc: use correct indentation for enumeration This creates hg.1.html as expected.

doc: use correct cross reference in help documentation This patch fixes problems below: - ":hg:" role should be followed by not '"' but '`' - there is a help topic not "default-push" but "config.default-push"

doc: prevent literal text block from being treated as non-literal one This creates hg.1.html as expected.

doc: prevent non-literal text block from being treated as literal one This creates hg.1.html as expected.

histedit: show correct hash ID at verification error node.short() on 'ha' in verifyactions() causes broken hash ID, because it is initialized with node.hex()-ed node value.

backout: disable --merge with --no-commit (issue4874) Because "backout --merge" have to make a commit before merging, it doesn't work with --no-commit. We could change "backout --merge" to make a merge commit automatically, and --no-commit to bypass a merge commit, but that change would be undesirable because: a) it's hard to fix bad merges in general b) two commits would be created with the same --message So, this patch simply disables "--merge --no-commit".

changegroup: fix pulling to treemanifest repo from flat repo (issue5066) In c0f11347b107 (changegroup: don't support versions 01 and 02 with treemanifests, 2016-01-19), I stopped supporting use of cg1 and cg2 with treemanifest repos. What I had not considered was that it's perfectly safe to pull *to* a treemanifest repo using any changegroup version. As reported in issue5066, I therefore broke pull from old repos into a treemanifest repo. It was not covered by the test case, because that pulled from a local repo while enabling treemanifests, which enabled treemanifests on the source repo as well. After switching to pulling via HTTP, it breaks. Fix by splitting up changegroup.supportedversions() into supportedincomingversions() and supportedoutgoingversions().

tests: minor cleanup to treemanifest test

merge: don't try to merge subrepos twice (issue4988) In my patch series ending with rev 25e4b2f000c5 I switched most change/delete conflicts to be handled at the resolve layer. .hgsubstate was the one file that we weren't able to handle, so we kept the old code path around for it. The old code path added .hgsubstate to one of the other lists as the user specifies, including possibly the 'g' list. Now since we did this check after converting the actions from being keyed by file to being keyed by action type, there was nothing that actually removed .hgsubstate from the 'cd' or 'dc' lists. This meant that the file would eventually make its way into the 'mergeactions' list, now freshly augmented with 'cd' and 'dc' actions. We call subrepo.submerge for both 'g' actions and merge actions. This means that if the resolution to an .hgsubstate change/delete conflict was to add it to the 'g' list, subrepo.submerge would be called twice. It turns out that this doesn't cause any adverse effects on Linux due to caching, but apparently breaks on other operating systems including Windows. The fix here moves this to before we convert the actions over. This ensures that it .hgsubstate doesn't make its way into multiple lists. The real fix here is going to be: (1) move .hgsubstate conflict resolution into the resolve layer, and (2) use a real data structure for the actions rather than shuffling data around between lists and dictionaries: we need a hash (or prefix-based) index by file and a list index by action type. There's a very tiny behavior change here: collision detection on case-insensitive systems will happen after this is resolved, not before. I think this is the right change -- .hgsubstate could theoretically collide with other files -- but in any case it makes no practical difference. Thanks to Yuya Nishihara for investigating this.

bookmarks: improve documentation for --rev option

merge: undocument checkunknown and checkignored configs for 3.7 We've discovered an issue with this flag during certain kinds of rebases. When: (1) we're rebasing while currently on the destination commit, and (2) an untracked or ignored file F is currently in the working copy, and (3) the same file F is in a source commit, and (4) F has different contents in the source commit, then we'll try to merge the file rather than overwrite it. An earlier patch I sent honored the options for these situations as well. Unfortunately, rebases go through the same flow as the old, deprecated 'hg merge --force'. We'd rather not make any changes to 'hg merge --force' behavior, and there's no way from this point in the code to figure out whether we're in 'hg rebase' or 'hg merge --force'. Pierre-Yves David and I came up with the idea to split the 'force' flag up into 'force' for rebases, and 'forcemerge' for merge. Since this is a very disruptive change and we're in freeze mode, simply undocument the options for this release so that our hands aren't tied by BC concerns. We'll redocument them in the next release.

commands: advance current active bookmark at pull --update correctly Before this patch, "hg pull --update" doesn't advance current active bookmark correctly, if pulling itself doesn't advance it, even though "hg pull" + "hg update" does so. Existing test for "pull --update works the same as pull && update" in test-bookmarks.t doesn't examine this case, because pulling itself advance current active bookmark before actual updating the working directory in that test case. To advance current active bookmark at "hg pull --update" correctly, this patch examines 'movemarkfrom' instead of 'not checkout'. Even if 'not checkout' at the invocation of postincoming(), 'checkout' is overwritten by "the revision to update to" value returned by destutil.destupdate() in such case. Therefore, 'not checkout' condition means "update destination is revision #0", and isn't suitable for examining whether active bookmark should be advanced. Even though examination around "movemarkfrom == repo['.'].node()" may seem a little redundant just for this issue, this makes it easier to compare (and unify in the future, maybe) with the same logic to update bookmark at "hg update" below. if not ret and movemarkfrom: if movemarkfrom == repo['.'].node(): pass # no-op update elif bookmarks.update(repo, [movemarkfrom], repo['.'].node()): ui.status(_("updating bookmark %s\n") % repo._activebookmark) else: # this can happen with a non-linear update ui.status(_("(leaving bookmark %s)\n") % repo._activebookmark) bookmarks.deactivate(repo)

largefiles: prevent committing a missing largefile Previously, if the largefile was deleted at the time of a commit, the standin was silently not updated and its current state (possibly garbage) was recorded. The test makes it look like this is somewhat of an edge case, but the same thing happens when an `hg revert` followed by `rm` changes the standin. Aside from the second invocation of this in lfutil.updatestandinsbymatch() (which is what triggers this test case), the three other uses are guarded by dirstate checks for added or modified, or an existence check in the filesystem. So aborting in lfutil.updatestandins() should be safe, and will avoid silent skips in the future if this is used elsewhere.