Martin von Zweigbergk <martinvonz@google.com> [Sun, 09 Nov 2014 00:10:29 -0800] rev 23447
generate-working-copy-states: accept depth arguments on command line
Add a parameter to generate-working-copy-states.py that indicates
how many changesets are wanted. This number impacts all the
subcommands. The current 'filelist' subcommand becomes 'filelist 2',
the current 'base' and 'parent' subcommands become 'state 2 1' and
'state 2 2' respectively, while 'wc' becomes 'state 2 wc'.
See earlier patch for motivation.
Martin von Zweigbergk <martinvonz@google.com> [Sat, 08 Nov 2014 23:37:54 -0800] rev 23446
generate-working-copy-states: generalize for depth
The script can currently generate filenames and contents for exactly
two changesets plus the working copy. For some tests (e.g. of plain
dirstate status), only one changeset is needed, while for others
(e.g. merge), three changesets are needed. Let's prepare for such
tests by generalizing the code for any number of changesets.
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Nov 2014 14:39:33 -0800] rev 23445
generate-working-copy-states: make 'tracked' a string
The only places the 'tracked' variable is only used is where it's
converted to a string, so let's simplify by using the string value
directly.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Dec 2014 13:28:07 -0800] rev 23444
merge: demonstrate that directory renames can lose local file content
When a directory has been renamed on the local branch and a file has
been added in the old location on a remote branch, we move that new
file to the new location. Unfortunately, if there is already a file
there, we overwrite it with the contents from the remote branch. For
untracked local files, we should probably abort, and for tracked local
files, we should merge the contents. To start with, let's add a test
to demonstrate the breakage. Also note that while files merged in from
a remote branch are normally (and unintuitively) reported as modified,
these files are reported as added.
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Nov 2014 03:09:19 +0100] rev 23443
mq: drop updateheader - inserthgheader and insertplainheader is enough
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Nov 2014 03:09:06 +0100] rev 23442
mq: smarter handling of plain headers
6333412245ec and 5ccced6eab0b fixed issue4453 with a simple insertplainheader
function that fixed the regression but didn't make the implementation more
stable.
Now we introduce plain header handling similar to how we handle hg patches. The
whole header is scanned for fields to update while determining the best
position for inserting the field if it is missing. It also makes sure there is
an empty line between headers and body.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 30 Nov 2014 23:30:31 -0500] rev 23441
largefiles: drop the override for 'fetch'
The fetch extension has been calling cmdutil.bailifchanged() since a014fdc97154,
so this is redundant. Add test coverage to prevent regression. It doesn't look
like there is any testing for fetch with largefiles.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 11:06:38 -0800] rev 23440
rebase: ignore negative state when updating back to original wc parent
The state mapping also contains some magic negative values (detached
parent, ignored revision). Blindly reading the state thus lead to
unfortunate usage of the negative value as an update destination. We
now filter them out.
We do a minor alteration of the test to catch this.
Eric Sumner <ericsumner@fb.com> [Fri, 21 Nov 2014 15:50:38 -0800] rev 23439
bundle2-push: provide transaction to reply unbundler
This patch series is intended to allow bundle2 push reply part handlers to
make changes to the local repository; it has been developed in parallel with
an extension that allows the server to rebase incoming changesets while applying
them.
This diff adds an experimental config option "bundle2.pushback" which provides
a transaction to the reply unbundler during a push operation. This behavior is
opt-in because of potential security issues: the response can contain any part
type that has a handler defined, allowing the server to make arbitrary changes
to the local repository.
Eric Sumner <ericsumner@fb.com> [Mon, 24 Nov 2014 16:04:44 -0800] rev 23438
bundle2.processbundle: let callers request default behavior
This patch series is intended to allow bundle2 push reply part handlers to
make changes to the local repository; it has been developed in parallel with
an extension that allows the server to rebase incoming changesets while applying
them.
The default transaction getter for processbundle is a private function that
raises an exception; this diff lets calling code pass None as the transaction
getter to explicitly request this default behavior.
The next diff will check a config option to determine whether to provide a
transaction to the reply bundle processor. If one shouldn't be provided, the
code needs a way to specify that the default behavior should be used.
Eric Sumner <ericsumner@fb.com> [Fri, 21 Nov 2014 15:06:38 -0800] rev 23437
push: elevate phase transaction to cover entire operation
This patch series is intended to allow bundle2 push reply part handlers to
make changes to the local repository; it has been developed in parallel with
an extension that allows the server to rebase incoming changesets while applying
them.
Most pushes already open a transaction in order to sync phase information.
This diff replaces that transaction with one that spans the entire push
operation.
This transaction will be used in a later patch to guard repository changes
made during the reply handler.
Eric Sumner <ericsumner@fb.com> [Fri, 21 Nov 2014 14:32:57 -0800] rev 23436
pull: extract transaction logic into separate object
This patch series is intended to allow bundle2 push reply part handlers to
make changes to the local repository; it has been developed in parallel with
an extension that allows the server to rebase incoming changesets while applying
them.
Aside from the transaction logic, the pulloperation class is used primarily as
a logic-free data structure for storing state information. This diff extracts
the transaction logic into its own class that can be shared with push
operations.
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 20:00:37 -0800] rev 23435
record: don't honor format-changing diffopts (issue4459)
record does support the whitespace options, so honor those. In upcoming patches
we'll replace all the other uses.
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 17:22:03 -0800] rev 23434
patch.difffeatureopts: add a feature for format-changing diffopts
Typically, callers that are interested in this set are also interested in the
others. We still add it as a first-class flag for convenience.
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 17:09:26 -0800] rev 23433
patch.difffeatureopts: add a feature for whitespace diffopts
These aren't exactly format-breaking features -- just ones for which patches
applied to a repo will produce incorrect commits, In any case, some commands
like record and annotate only care about this feature.
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 17:10:14 -0800] rev 23432
patch.difffeatureopts: add a feature for diff.git
This deserves to be its own feature -- indeed, this is often the only feature
several commands care about.
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 21:43:38 -0800] rev 23431
patch: rename diffopts to diffallopts
This is meant to be used when all features are explicitly requested. diffopts
is kept as an alias for now -- it will go away soon.
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 16:53:22 -0800] rev 23430
patch: add a new function to initialize diffopts by feature
Not all callers are interested in all diffopts -- for example, commands like
record (which use diff internally) break when diffopts like noprefix are
enabled. This function will allow us to add flags that callers can use to
enable only the features they're interested in.
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.
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.
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.
Matt Mackall <mpm@selenic.com> [Mon, 01 Dec 2014 19:34:11 -0600] rev 23426
merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 01 Dec 2014 18:51:10 -0600] rev 23425
merge with i18n
Wagner Bruna <wbruna@softwareexpress.com.br> [Mon, 01 Dec 2014 11:21:30 -0200] rev 23424
i18n-pt_BR: synchronized with 3bd577a3283e
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 29 Nov 2014 14:32:12 +0900] rev 23423
i18n-ja: synchronized with edf29f9c15f0
Matt Mackall <mpm@selenic.com> [Mon, 01 Dec 2014 18:39:19 -0600] rev 23422
Added signature for changeset 902554884335
Matt Mackall <mpm@selenic.com> [Mon, 01 Dec 2014 18:39:14 -0600] rev 23421
Added tag 3.2.2 for changeset 902554884335
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.