Siddharth Agarwal <sid0@fb.com> [Thu, 12 Nov 2015 14:29:02 -0800] rev 26949
merge.applyupdates: only attempt to merge files in mergeactions
This only makes a difference when a merge driver is active -- in that case we
don't want to try and merge all the files, just the ones still unresolved after
the merge driver's preprocess step is over.
Siddharth Agarwal <sid0@fb.com> [Wed, 11 Nov 2015 17:34:28 -0800] rev 26948
filemerge: rename _symlinkcheck to _mergecheck
We're going to be adding other checks in here soon.
Siddharth Agarwal <sid0@fb.com> [Wed, 11 Nov 2015 17:32:41 -0800] rev 26947
test-merge-prompt.t: rename to test-merge-changedelete.t
Because:
(a) the only prompts we test in this file are change/delete prompts, and
(b) we're going to be expanding the scope of this test to cover future
improvements to change/delete conflicts, including avoiding prompts
altogether.
Matt Mackall <mpm@selenic.com> [Thu, 12 Nov 2015 20:48:41 -0600] rev 26946
merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 12 Nov 2015 13:16:04 -0800] rev 26945
tags: create new sortdict for performance reasons
sortdict internally maintains a list of keys in insertion order. When a
key is replaced via __setitem__, we .remove() from this list. This
involves a linear scan and array adjustment. This is an expensive
operation.
The tags reading code was calling into sortdict.__setitem__ for each tag
in a read .hgtags revision. For repositories with thousands of tags or
thousands of .hgtags revisions, the overhead from list.remove()
noticeable.
This patch creates a new sortdict() so __setitem__ calls don't incur a
list.remove.
This doesn't appear to have any performance impact on my Firefox
repository. But that's only because tags reading doesn't show up in
profiles to begin with. I'm still waiting to hear from a user with over
10,000 tags and hundreds of heads on the impact of this patch.
Christian Delahousse <cdelahousse@fb.com> [Tue, 10 Nov 2015 15:08:56 -0800] rev 26944
largefiles: specify where .orig files are kept
This patch let's the user specify where .orig files are kept using the
cmdutil.origpath function
Christian Delahousse <cdelahousse@fb.com> [Tue, 10 Nov 2015 14:52:54 -0800] rev 26943
mq: let the user choose where .orig files are kept
This patch uses cmdutil.origpath to let the user decide where .orig files are
kept when backup files are created.
Christian Delahousse <cdelahousse@fb.com> [Tue, 10 Nov 2015 14:41:14 -0800] rev 26942
shelve: choose where .orig file locations are kept
This patch uses cmdutil.origpath to let the user set the location of the orig
files.
Christian Delahousse <cdelahousse@fb.com> [Tue, 10 Nov 2015 16:25:59 -0800] rev 26941
filemerge: choose where .orig files are kept
Having .orig files litter your working copy is a common complaint. This patch
uses cmdutil.orig to let the user determine where those files should reside.
Christian Delahousse <cdelahousse@fb.com> [Tue, 10 Nov 2015 14:29:13 -0800] rev 26940
git-subrepos: revert respects specified location to save .orig files
This patch makes revert in git subrepos save .orig files where the user wants
them by using the cmdutil.origpath function.