Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Nov 2014 05:53:04 -0800] rev 23544
merge: perform case-collision checking on final set of actions
When there are multiple common ancestors, we should check for case
collisions only on the resulting actions after bid merge has run. To
do this, move the code until after bid merge.
Move it past _resolvetrivial() too, since that might update
actions. If the remote changed a file and then reverted the change,
while the local side deleted the file and created a new file with a
name that case-folds like the old file, we should fail before this
patch but not after.
Although the changes to the actions caused by _forgetremoved() should
have no effect on case collisions, move it after that, too, so the
next person reading the code won't have to think about it.
Moving it past these blocks of code takes it to the end of
calculateupdates(), so let's even move it outside of the method, so we
also check collisions in actions produced by extensions overriding the
method.
Mads Kiilerich <madski@unity3d.com> [Thu, 17 Apr 2014 22:47:38 +0200] rev 23543
spelling: fixes from proofreading of spell checker issues
Mathias De Maré <mathias.demare@gmail.com> [Sat, 13 Dec 2014 09:45:00 +0100] rev 23542
tests: allow more flexibility in git diffstat output
The output of 'git diff --stat' changed in git 1.7.10 and 1.7.11.
To ensure the tests work with earlier versions of git as well,
the output is now wrapped with a whitespace regex.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Dec 2014 21:21:21 -0800] rev 23541
merge: move cd/dc prompts after largefiles prompts
By moving the cd/dc prompts out of calculateupdates(), we let
largefiles' overridecalculateupdates() so the unresolved values
(i.e. 'cd' or 'dc' rather than 'g', 'r', 'a' and missing). This allows
overridecalculateupdates() to ask the user whether to keep the normal
file or the largefile before the user gets the cd/dc prompt. Whichever
answer the user gives, we make overridecalculateupdates() replace 'cd'
or 'dc' action, saving the user one annoying (and less clear)
question.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 30 Nov 2014 22:47:53 -0500] rev 23540
addremove: automatically process a subrepository's subrepos
Since addremove on the top of a directory tree will recursively handle sub
directories, it should be the same with deep subrepos, once the user has
explicitly asked to process a subrepo. This really only has an effect when a
path that is a subrepo (or is in a subrepo) is given, since -S causes all
subrepos to be processed already. An addremove without a path that crosses into
a subrepo, will still not enter any subrepos, per backward compatibility rules.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Nov 2014 23:46:25 -0500] rev 23539
addremove: support addremove with explicit paths in subrepos
Git and svn subrepos are currently not supported.
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Nov 2014 23:51:26 -0500] rev 23538
addremove: add support for the -S flag
Git and svn subrepos are currently not supported. It doesn't look like git or
svn have these commands natively, so that's an area for a git or svn expert.
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Nov 2014 22:27:49 -0500] rev 23537
commit: propagate --addremove to subrepos if -S is specified (
issue3759)
The recursive addremove operation occurs completely before the first subrepo is
committed. Only hg subrepos support the addremove operation at the moment- svn
and git subrepos will warn and abort the commit.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 26 Nov 2014 16:13:38 -0500] rev 23536
subrepo: store the ui object in the base class
This will be used in the next patch to print a warning from the base class. It
seems better than having to explicitly pass it to a new method, since a lot of
existing methods also require it.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 26 Nov 2014 15:16:22 -0500] rev 23535
commit: abort if --addremove is specified, but fails
This will be required when subrepo support is added, in order to ensure
consistent commits when a subrepo flavor doesn't support addremove.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 26 Nov 2014 14:27:36 -0500] rev 23534
addremove: warn when addremove fails to operate on a named path
It looks like a bad path is the only mode of failure for addremove. This
warning is probably useful for the standalone command, but more important for
'commit -A'. That command doesn't currently abort if the addremove fails, but
it will be made to do so prior to adding subrepo support, since not all subrepos
will support addremove. We could just abort here, but it looks like addremove
has always silently ignored bad paths, except for the exit code.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Nov 2014 19:57:02 -0500] rev 23533
scmutil: pass a matcher to scmutil.addremove() instead of a list of patterns
This will make it easier to support subrepository operations.
Enrique A. Tobis <enrique@tobis.com.ar> [Wed, 10 Dec 2014 23:46:47 -0500] rev 23532
tests: fix a typo in test-walkrepos.py
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 13:50:28 -0800] rev 23531
merge: extract _resolvetrivial() function
We would eventually like to move the resolution of modify/delete and
delete/modify conflicts to the resolve phase. However, we don't want
to move the checks for identical content that were added in
902554884335 (merge: before cd/dc prompt, check that changed side
really changed, 2014-12-01). Let's instead move these out to a new
_resolvetrivial() function that processes the actions from
manifestmerge() and replaces any false cd/dc conflicts. The function
will also provide a natural place for us to later add code for
resolving false 'm' conflicts.