Fri, 31 Oct 2014 21:34:55 -0400 extdiff: allow a preconfigured merge-tool to be invoked
Matt Harbison <matt_harbison@yahoo.com> [Fri, 31 Oct 2014 21:34:55 -0400] rev 23150
extdiff: allow a preconfigured merge-tool to be invoked There are three ways to configure an extdiff tool: 1) cmd.tool = (/path/to/exe optional) 2) tool = (path/to/exe optional) 3) tool = sometool someargs Previously, if no executable is specified in the first two forms, the named tool must be in $PATH, or the invocation fails. Since the [merge-tools] section already has the path to the diff executable, and/or the registry keys to find the executable on Windows, reuse that configuration for forms 1 and 2 instead of failing. We already fallback to [diff-tools] and then [merge-tools] for program arguments if they aren't specified in the [extdiff] section. Since this additional lookup only occurs if an executable is not on the $PATH for the named tool, this is backwards compatible. For now, we assume the user knows what he is doing if a path is provided. This change allows a configuration file like this (assuming beyondcompare3 is configured in merge-tools), instead of hardcoding system specific a path: [extdiff] beyondcompare3 =
Mon, 03 Nov 2014 16:30:21 -0600 extdiff: sort files when snapshotting
Matt Mackall <mpm@selenic.com> [Mon, 03 Nov 2014 16:30:21 -0600] rev 23149
extdiff: sort files when snapshotting This fixes output stability and is generally filesystem-performance-friendly.
Sun, 02 Nov 2014 14:58:50 -0500 filemerge: split the logic for finding an external tool to its own function
Matt Harbison <matt_harbison@yahoo.com> [Sun, 02 Nov 2014 14:58:50 -0500] rev 23148
filemerge: split the logic for finding an external tool to its own function This will be used by extdiff in an subsequent patch.
Sun, 02 Nov 2014 13:18:08 -0800 largefiles: simplify check for lack of path arguments
Martin von Zweigbergk <martinvonz@google.com> [Sun, 02 Nov 2014 13:18:08 -0800] rev 23147
largefiles: simplify check for lack of path arguments Instead of checking for a partial merge by checking that the matches has no files and no patterns, check that it's not an always-matcher. Except for being shorter, it also catches the rare case of an exact-matcher with no files.
Fri, 31 Oct 2014 14:11:47 -0700 largefiles: shortcircuit status code also for non-matching patterns
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 Oct 2014 14:11:47 -0700] rev 23146
largefiles: shortcircuit status code also for non-matching patterns We currently shortcircuit the checking for large file standins if only patterns of type 'path' are given on the command line. That makes e.g. "hg st 'glob:foo/**'" unnecessarily slow when the only large files are in a sibling directory. Relax the check to be that it is not an always-matcher and that no large files match the patterns given on the command line. Note that before this change, only the latter of the following two would show the status of files in .hglf (since the -I makes match.anypats() true). After this change, they both display the status. This behavior doesn't seem correct, but it would be a separate change to explicitly filter out .hglf even in the shortcircuit case. hg st .hglf/$file hg st .hglf/$file -I .
Mon, 27 Oct 2014 21:10:24 -0700 largefiles: remove confusing 'or None' from predicate
Martin von Zweigbergk <martinvonz@google.com> [Mon, 27 Oct 2014 21:10:24 -0700] rev 23145
largefiles: remove confusing 'or None' from predicate The match function that is overriden returns a boolean value, so adding 'or None' is both unnecessary and confusing.
Thu, 30 Oct 2014 22:32:39 -0700 largefiles: drop unnecessary setting of matcher._always
Martin von Zweigbergk <martinvonz@google.com> [Thu, 30 Oct 2014 22:32:39 -0700] rev 23144
largefiles: drop unnecessary setting of matcher._always In two very similar segments of code, an existing matcher is modified by changing its _files attribute through a map and a filter operation. Neither operation can cause an empty list to become non-empty, so a matcher that always matches can not stop always matching. Drop the setting of the attribute, so we don't unnecessarily prevent the fast paths to be taken where these matchers end up being used.
Sun, 19 Oct 2014 03:22:23 +0200 config: move mergetools configuration from contrib to default configuration
Mads Kiilerich <madski@unity3d.com> [Sun, 19 Oct 2014 03:22:23 +0200] rev 23143
config: move mergetools configuration from contrib to default configuration The merge tool configuration is an essential part of a good initial user experience. 'make osx' installers and direct 'make' installation did not have merge tool configuration. Now they have. Note: The installer fixes for windows have been done blindly and might require additional changes.
Thu, 04 Sep 2014 21:36:35 +0200 config: introduce "built-in" default configuration settings in default.d
Mads Kiilerich <madski@unity3d.com> [Thu, 04 Sep 2014 21:36:35 +0200] rev 23142
config: introduce "built-in" default configuration settings in default.d This helps providing a more consistent user experience on all platforms and with all packaging. The exact location of default.d depends on how Mercurial is installed and whether it is 'frozen'. The exact location should never be relevant to users and is intentionally not explained in details in the documentation. It will however always be next to the help and templates files. Note that setting HGRCPATH also disables these defaults. I don't know if that should be considered a bug or a feature.
Sat, 18 Oct 2014 21:48:38 +0200 contrib: buildrpm checking of md5 checksums of downloaded Python and Docutils
Mads Kiilerich <madski@unity3d.com> [Sat, 18 Oct 2014 21:48:38 +0200] rev 23141
contrib: buildrpm checking of md5 checksums of downloaded Python and Docutils
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip