Tue, 18 Nov 2014 16:00:54 -0800 patch.diffopts: use a dict for initialization
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 16:00:54 -0800] rev 23429
patch.diffopts: use a dict for initialization In upcoming patches we'll conditionally add to and remove from the dict.
Fri, 21 Nov 2014 22:24:45 -0500 largefiles: split the creation of a normal matcher out of its install method
Matt Harbison <matt_harbison@yahoo.com> [Fri, 21 Nov 2014 22:24:45 -0500] rev 23428
largefiles: split the creation of a normal matcher out of its install method Refactoring addremove to support subrepos will need the ability to keep passing the same matcher and narrowing it, instead of monkey patching scmutil's matcher.
Mon, 01 Dec 2014 21:48:32 -0800 addremove: print relative paths when called with -I/-X (BC)
Martin von Zweigbergk <martinvonz@google.com> [Mon, 01 Dec 2014 21:48:32 -0800] rev 23427
addremove: print relative paths when called with -I/-X (BC) For "hg addremove 'glob:*.py'", we print any paths added or removed as relative to the current directory, but when "hg addremove -I 'glob:*.py'" is used, we use the absolute path (relative from the repo root). It seems like they should be the same, so change it so we use relative paths in both cases. Continue to use absolute paths when no patterns are given.
Mon, 01 Dec 2014 19:34:11 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 01 Dec 2014 19:34:11 -0600] rev 23426
merge with stable
Mon, 01 Dec 2014 18:51:10 -0600 merge with i18n stable
Matt Mackall <mpm@selenic.com> [Mon, 01 Dec 2014 18:51:10 -0600] rev 23425
merge with i18n
Mon, 01 Dec 2014 11:21:30 -0200 i18n-pt_BR: synchronized with 3bd577a3283e stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Mon, 01 Dec 2014 11:21:30 -0200] rev 23424
i18n-pt_BR: synchronized with 3bd577a3283e
Sat, 29 Nov 2014 14:32:12 +0900 i18n-ja: synchronized with edf29f9c15f0 stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 29 Nov 2014 14:32:12 +0900] rev 23423
i18n-ja: synchronized with edf29f9c15f0
Mon, 01 Dec 2014 18:39:19 -0600 Added signature for changeset 902554884335 stable
Matt Mackall <mpm@selenic.com> [Mon, 01 Dec 2014 18:39:19 -0600] rev 23422
Added signature for changeset 902554884335
Mon, 01 Dec 2014 18:39:14 -0600 Added tag 3.2.2 for changeset 902554884335 stable
Matt Mackall <mpm@selenic.com> [Mon, 01 Dec 2014 18:39:14 -0600] rev 23421
Added tag 3.2.2 for changeset 902554884335
Mon, 01 Dec 2014 02:30:21 +0100 merge: before cd/dc prompt, check that changed side really changed stable 3.2.2
Mads Kiilerich <madski@unity3d.com> [Mon, 01 Dec 2014 02:30:21 +0100] rev 23420
merge: before cd/dc prompt, check that changed side really changed Before, merging would in some cases ask "wrong" questions about "changed/deleted" conflicts ... and even do it before the resolve phase where they can be postponed, re"resolved" or answered in bulk operations. Instead, check that the content of the changed file really did change. Reading and comparing file content is expensive and should be avoided before the resolve phase. Prompting the user is however even more expensive. Checking the content here is thus better. The 'f in ancestors[0]' should not be necessary but is included to be extra safe.
Mon, 01 Dec 2014 02:11:29 +0100 largefiles: don't show largefile/normal prompts if one side is unchanged stable
Mads Kiilerich <madski@unity3d.com> [Mon, 01 Dec 2014 02:11:29 +0100] rev 23419
largefiles: don't show largefile/normal prompts if one side is unchanged
Mon, 01 Dec 2014 02:11:17 +0100 tests: add test-issue3084.t cases for 'changed but same' as for 'unchanged' stable
Mads Kiilerich <madski@unity3d.com> [Mon, 01 Dec 2014 02:11:17 +0100] rev 23418
tests: add test-issue3084.t cases for 'changed but same' as for 'unchanged' Use suffix -same for cases where file changed but content is the same - that is the case where manifestmerge doesn't detect that a file is unchanged. (The suffix -id is already used for cases where the file didn't change - that is the trivial case where manifestmerge detects that the file is unchanged.) These new tests are good but the results are bad. There shouldn't be any merge conflicts or prompts when one side didn't change.
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip