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.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 22:10:51 -0800] rev 23530
largefiles: start by finding files of interest
Instead of iterating over 'g' action, first find the set of all files
that are largefiles in p1. Then iterate over these files. This
prepares for considering actions other than 'g'.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 22:03:53 -0800] rev 23529
largefiles: rewrite merge code using dictionary with entry per file
In overridecalculateupdates(), we currently only deal with conflicts
that result in a 'g' action for either the largefile or a standin. We
will soon want to deal cases with 'cd' and 'dc' actions here. It will
be easier to reason about such cases if we rewrite it using a dict
from filename to action.
A side-effect of this change is that the output can only have one
action per file (which should be a good change). Before this change,
when one of the tests in test-
issue3084 received this input (the 'a'
in the input was a result of 'cd' conflict resolved in favor of the
modified file):
'g': [('.hglf/f', ('',), 'remote created')],
'a': [('f', None, 'prompt keep')],
and the user chose to keep the local largefile, it produced this
output:
'g': [('.hglf/f', ('',), 'remote created')],
'r': [('f', None, 'replaced by standin')],
'a': [('f', None, 'prompt keep')],
Although 'a' actions are processed after 'r' actions by
recordupdates(), it still worked because 'a' actions have no effect on
merges (only on updates). After this change, the output is:
'g': [('.hglf/f', ('',), 'remote created')],
'r': [('f', None, 'replaced by standin')],
Similarly, there are several tests in test-largefiles-update that get
inputs like:
'a': [('.hglf/large2', None, 'prompt keep')],
'g': [('large2', ('',), 'remote created')],
and when the user chooses to keep the local largefile, they produce
this output:
'a': [('.hglf/large2', None, 'prompt keep'),
('.hglf/large2', None, 'keep standin')],
'lfmr': [('large2', None, 'forget non-standin largefile')],
In this case, it was not a merge but an update, so the 'a' action does
have an effect. However, since dirstate.add() is idempotent, it still
has no obserable effect.
After this change, the output is:
'a': [('.hglf/large2', None, 'keep standin')],
'lfmr': [('large2', None, 'forget non-standin largefile')],
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 09:53:26 -0800] rev 23528
largefiles: put same 'action' object back in 'newglist'
The items we put in 'newglist' are always the same as what we found in
actions['g'], so let's just put the same item into the list instead of
creating a new one.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 08 Dec 2014 15:20:42 -0800] rev 23527
largefiles: don't unnecessarily sort merge action lists
The action lists returned from calculateupdates() (in merge.py) are
not required to be sorted. In fact, since they result from iteration
over the unordered manifest, they are unlikely to be sorted. Moreover,
some of the lists are appended to after they are returned from
manifestmerge(). The lists are instead sorted in
applyupdates(). Therefore, let's not sort the lists generated in
largefiles' overridecalculateupdates().
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 16:49:55 -0800] rev 23526
merge: don't treat 'diverge' and 'renamedelete' like actions
See earlier patch for motivation.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 14:18:31 -0800] rev 23525
merge: move dr/rd warning messages out of applyupdates()
As preparation for making 'dr' and 'rd' actions no longer actions,
move the reporting from applyupdates() to its caller update(). This
way we won't have to pass additonal arguments to applyupdates() when
they are no longer actions. Also, the warnings are equally unrelated
to applyupdates() as they are to recordupdates(), as they don't result
in any changes to either the working copy or the dirstate.
See earlier patch for additional motivation.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 16:13:26 -0800] rev 23524
merge: don't report progress for dr/rd actions
It is easier to reason about certain algorithms in terms of a
file->action mapping than the current action->list-of-files. Bid merge
is already written this way (but with a list of actions per file), and
largefiles' overridecalculateupdates() will also benefit. However,
that requires us to have at most one action per file. That requirement
is currently violated by 'dr' (divergent rename) and 'rd' (rename and
delete) actions, which can exist for the same file as some other
action.
These actions are only used for displaying warnings to the user; they
don't change anything in the working copy or the dirstate. In this
way, they are similar to the 'k' (keep) action. However, they are even
less action-like than 'k' is: 'k' at least describes what to do with
the file ("do nothing"), while 'dr' and 'rd' or only annotations for
files for which there may exist other, "real" actions.
As a first step towards separating these acitons out, stop including
them in the progress output, just like we already exclude the 'k'
action.
Mathias De Maré <mathias.demare@gmail.com> [Wed, 10 Dec 2014 10:32:51 +0100] rev 23523
subrepo: add partial diff support for git subrepos
So far, git subrepositories were silently ignored for diffs.
This patch adds support for git subrepositories,
with the remark that --include and --exclude are not supported.
If --include or --exclude are used, the subrepo is ignored.
Mathias De Maré <mathias.demare@gmail.com> [Wed, 10 Dec 2014 08:41:21 +0100] rev 23522
subrepo: extend git version check to 3 digits
This allows more flexibility when a version check is required.
Some git features are introduced in a version where only
the 3rd digit changes.
Mathias De Maré <mathias.demare@gmail.com> [Wed, 10 Dec 2014 08:33:03 +0100] rev 23521
subrepo: move git version check into a separate method
This allows checking the git version in other methods,
instead of only being able to check if the version is ok or not.
Mads Kiilerich <mads@kiilerich.com> [Thu, 11 Oct 2012 23:22:02 +0200] rev 23520
rebase: show a note for updated mq patches
It deserves more than a debug message. Show a note like:
updating mq patch p0.patch to 5:
9ecc820b1737
The message could also refer to "qrefresh" instead. Same same.