Mercurial: Changelog

obsstore: make the invalid markers check wrap-able Some evolve user ignored the invalid markers for about two years and still have some of them in some repository. This lead to plain abort whenever mercurial try to open such repo. We need reinstall some way to clean this up in the evolve extension. For this purpose, we need the checker code wrap-able independently. This is scheduled for stable as this issue is blocking some evolve user.

convert: replace revision references in messages if they are >= short hashes Convert will try to find references to revisions in commit messages and replace them with references to the converted revision. It will take any string that looks like a hash (and thus also decimal numbers) and look it up in the source repo. If it finds anything, it will use that in the commit message instead. It would do that for all hex digit sequences of 6 to 40 characters. That was usually no problem for small repos where it was unlikely that there would be a matching 6 'digit' hash prefix. It was also no problem on repos with less than 100000 changesets where numbers with 6 or more digits not would match any revision number. With more than 100000 revisions random numbers in commit messages would be replaced with a "random" hash. For example, 'handle 100000 requests' would be changed to to 'handle 9117c6 requests'. Convert could thus not really be used on real repositories with more than 100000 changesets. The default hash length shown by Mercurial is 12 'digits'. It is unexpected and unwanted that convert by default tries to replace revision references that use less than that amount of 'digits'. To fix this, don't match strings that are less than the default hash size of 12 characters.

merge: mark .hgsubstate as possibly dirty before submerge for consistency Before this patch, failure of updating subrepos may cause inconsistent ".hgsubstate". For example: 1. dirstate entry for ".hgsubstate" of the parent repo is filled with valid size/date (via "hg state" or so) 2. "hg update" is invoked at the parent repo 3. ".hgsubstate" of the parent repo is updated on the filesystem as a part of "g"(et) action in "merge.applyupdates" 4. it is assumed that size/date of ".hgsubstate" on the filesystem aren't changed from ones at (1) this is not so difficult condition, because just changing hash ids (every ids are same in length) in ".hgsubstate" doesn't change the file size of it 5. "subrepo.submerge()" is invoked to update subrepos 6. failure of updating in one of subrepos raises exception (e.g. "untracked file differs") 7. "hg update" is aborted without updating dirstate of the parent repo dirstate entry for ".hgsubstate" still holds size/date at (1) Then, ".hgsubstate" of the parent repo is treated as "CLEAN" unexpectedly, because updating ".hgsubstate" at (3) doesn't change size/date of it on the filesystem: see assumption at (4). This inconsistent ".hgsubstate" status causes unexpected behavior, for example: - "hg revert" forgets to revert ".hgsubstate" - "hg update" misunderstands that (not yet updated) subrepos diverge (then, it shows the prompt to confirm user's decision) To avoid inconsistent ".hgsubstate" status above, this patch marks ".hgsubstate" as possibly dirty before "submerge" invocation. "normallookup"-ed (= dirty) dirstate should be written out, even if processing is aborted by failure. This patch marks ".hgsubstate" as possibly dirty before "submerge", also when it is removed or merged while merging, for safety. This should prevent Mercurial from misunderstanding inconsistent ".hgsubstate" as clean. To satisfy conditions at (1) and (4) above, this patch uses "hg status --config debug.dirstate.delaywrite=2" (to fill valid size/date into dirstate) and "touch" (to fix date of the file).

rebase: ensure rebase revision remains visible (issue4504) Before this changeset rebase was getting very confused if any revision in the rebase set became hidden. This was fairly easy to achieve if a rebased revision was made visible by the working copy location. The rebase process would update somewhere else and the revision would become hidden. To work around this issue, we ensure rebased revisions remain visible for the whole process. This is a simple change suitable for stable. More subtle usage of unfiltered repository in rebase may solve this issue more cleanly.

extdiff: reintroduce backward compatibility with manual quoting of parameters 72a89cf86fcd broke things ... and the following cleanups didn't fix all issues. It didn't work with the diffargs shipped in mergetools.rc with explicit quoting. Parameters would end up with being quoted twice - especially if they really needed quoting. To work around that, look for explicit quotes around the variables that will be substituted with proper quoting. Also accept an additional prefix so we can handle both --foo='$parent' and '--foo=$parent' It will however still fail if the user intentionally place the variable inside a quoted string, as in 'parent $parent is on the left' There is currently no good way to handle that, short of knowing exactly which quoting mechanism will be used.

mergetools: drop incorrect quoting of diffargs variables 72a89cf86fcd introduced automatic quoting of diffargs in a not entirely backwards compatible way. That rendered some of the configuration in mergetools.rc invalid. It would fail when running extdiff on a single file with a name that needed quoting. Before: $ hg config merge-tools.meld.diffargs -a --label='$plabel1' $parent --label='$clabel' $child $ hg --config extdiff.meld= -v --debug meld running "/usr/bin/meld -a --label=''sp ace@0'' '.../Z.b7a65a1d2f84/sp ace' --label=''sp ace'' '.../sp ace'" in ... meld: error: too many arguments (wanted 0-3, got 4) After: $ hg config merge-tools.meld.diffargs -a --label=$plabel1 $parent --label=$clabel $child $ hg --config extdiff.meld= -v --debug meld running "/usr/bin/meld -a --label='sp ace@0' '.../Z.b7a65a1d2f84/sp ace' --label='sp ace' '.../sp ace'" in ... (success)

namespace: introduce logfmt to show l10n-ed messages for hg log correctly Before this patch, "_()" is used incorrectly for "tag:" and "bookmark:" fields. "changeset_printer()" looks up keys composed at runtime, and it prevents "xgettext" command from getting strings to be translated from source files. Then, *.po files merged with updated "hg.pot" lose msgids for "tag:" and "bookmark:". This patch introduces "logfmt" information into "namespace" to show l10n-ed messages "hg log" (or "changeset_printer()") correctly. For similarity to other namespaces, this patch specifies "logfmt" for "branches" namespace, even though it isn't needed (branch information is handled in "changeset_printer()" specially). To find related code paths out easily, this patch adds "i18n: column positioning ..." comment to the line composing "logfmt" by default, even though this line itself doesn't contain any strings to be translated.