Sat, 13 May 2017 03:31:42 +0900 filemerge: add internal merge tool to dump files forcibly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 13 May 2017 03:31:42 +0900] rev 32255
filemerge: add internal merge tool to dump files forcibly Internal merge tool :dump implies premerge. Therefore, files aren't dumped, if premerge runs successfully. This undocumented behavior might confuse users, if they want to always dump files. But just making :dump omit premerge might cause backward compatibility issue for existing automation. This patch adds new internal merge tool :forcedump, which works as same as :dump, but omits premerge always. Internal tools annotated with "nomerge" should merge "change and delete" correctly, but _forcedump() can't. Therefore, it is annotated with "mergeonly" to always omit premerge, even though it doesn't merge files actually. This patch also adds explanation about premerge to :dump, to clarify how :dump actually works. BTW, this patch specifies internal tools with "internal:" prefix in newly added test scenario in test-merge-tools.t, even though this prefix is already deprecated. This is only for similarity to other tests in test-merge-tools.t.
Sat, 13 May 2017 03:28:36 +0900 filemerge: make warning message more i18n friendly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 13 May 2017 03:28:36 +0900] rev 32254
filemerge: make warning message more i18n friendly Before this patch, " specified for " part of warning messages (e.g. "couldn't find merge tool TOOL specified for PAT") isn't translatable.
Sat, 13 May 2017 03:28:36 +0900 filemerge: show warning about choice of :prompt only at an actual fallback
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 13 May 2017 03:28:36 +0900] rev 32253
filemerge: show warning about choice of :prompt only at an actual fallback Before this patch, internal merge tool :prompt shows "no tool found to merge FILE" line, even if :prompt is explicitly specified as a tool to be used. This patch shows warning message about choice of :prompt only at an actual fallback, in which case any tool is rejected by capability for binary or symlink. It is for backward compatibility to omit warning message in "changedelete" case.
Tue, 09 May 2017 13:56:46 -0700 treemanifest: allow manifestrevlog to take an explicit treemanifest arg
Durham Goode <durham@fb.com> [Tue, 09 May 2017 13:56:46 -0700] rev 32252
treemanifest: allow manifestrevlog to take an explicit treemanifest arg Previously we relied on the opener options to tell the revlog to be a tree manifest. This makes it complicated for extensions to create treemanifests and normal manifests at the same time. Let's add a construtor argument to create a treemanifest revlog as well. I considered removing the options['treemanifest'] logic from manifestrevlog entirely, but doing so shifts the responsibility to the caller which ends up requiring changes in localrepo, bundlerepo, and unionrepo. I figured having the dual mechanism was better than polluting other parts of the code base with treemanifest knowledge.
Wed, 26 Apr 2017 23:02:43 +0900 policy: relax the default for in-place build
Yuya Nishihara <yuya@tcha.org> [Wed, 26 Apr 2017 23:02:43 +0900] rev 32251
policy: relax the default for in-place build We're going to make the 'c' policy more strict, where no missing attribute will be allowed. Since we want to run 'hg bisect' without rebuilding the C extension modules, we'll need a looser policy for development environment. The default for system installation isn't changed. Note that the current 'c' policy is practically 'allow'-ish as we have lots of adhoc fallbacks to pure functions.
Thu, 11 May 2017 14:52:02 -0700 verify: always check rawsize
Jun Wu <quark@fb.com> [Thu, 11 May 2017 14:52:02 -0700] rev 32250
verify: always check rawsize Previously, verify only checks "rawsize == len(rawtext)", if "len(fl.read()) != fl.size()". With flag processor, "len(fl.read()) != fl.size()" does not necessarily mean "rawsize == len(rawtext)". So we may miss a useful check. This patch removes the "if len(fl.read()) != fl.size()" condition so the rawsize check is always performed. With the condition removed, "fl.read(n)" looks unnecessary so a comment was added to explain the side effect is wanted.
Thu, 11 May 2017 22:38:15 -0700 rebase: rename "target" to "destination" in messages
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 May 2017 22:38:15 -0700] rev 32249
rebase: rename "target" to "destination" in messages The help text for rebase calls it "the destination" (never "target"), so let's use that in messages as well.
Thu, 11 May 2017 22:38:03 -0700 rebase: rename "target" to "dest" in variable names
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 May 2017 22:38:03 -0700] rev 32248
rebase: rename "target" to "dest" in variable names It took me a while to figure out that "target" was actually what's passed to --dest.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip