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.