Thu, 04 Dec 2014 23:08:27 -0500 addremove: restore the relative path printing when files are named
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Dec 2014 23:08:27 -0500] rev 23481
addremove: restore the relative path printing when files are named This fixes the previously mentioned issue with 3778884197f0, and undoes its corresponding test change. The test change demonstrates the correctness when a file is specified (i.e. the glob is required on Windows because relative paths use '\' and absolute paths use '/'). It is admittedly very subtle, but there will be a more robust test in the addremove -S v3 series.
Thu, 04 Dec 2014 23:04:55 -0500 match: introduce uipath() to properly style a file path
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Dec 2014 23:04:55 -0500] rev 23480
match: introduce uipath() to properly style a file path Several methods print files relative to the repo root, unless files are named on the command line, in which case they are printed relative to cwd. Since the check relies on the 'pats' parameter, which needs to be replaced by a matcher when adding subrepo support, this logic gets folded into the matcher to tidy up the callers. Prior to 3778884197f0, this style decision was based off of whether or not the 'pats' list was empty. That change altered the check to test match.anypats() instead, in order to make paths printed consistent when -I/-X is specified. That however, changed the style when a file is given to the command. So now we test the pattern list to get the old behavior for files, as well as test -I/-X to get the consistency for patterns.
Fri, 05 Dec 2014 12:10:56 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 05 Dec 2014 12:10:56 -0600] rev 23479
merge with stable
Sun, 16 Nov 2014 23:41:44 -0800 update: don't overwrite untracked ignored files on update stable
Martin von Zweigbergk <martinvonz@google.com> [Sun, 16 Nov 2014 23:41:44 -0800] rev 23478
update: don't overwrite untracked ignored files on update When looking for untracked files that would conflict with a tracked file in the target revision (or the remote side of a merge), we explcitly exclude ignored files. The code was added in 7e30f5f2285f (merge: refactor unknown file conflict checking, 2012-02-09), but it seems like only unknown, not ignored, files were considered since the beginning of time. Although ignored files are mostly build outputs and backup files, we should still not overwrite them. Fix by simply removing the explicit check.
Tue, 02 Dec 2014 17:11:01 -0800 update: add tests for untracked local file stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Dec 2014 17:11:01 -0800] rev 23477
update: add tests for untracked local file We don't seem to have any tests for updating to another revision when there are untracked files on the local side that conflict with the those on the remote side, so let's add tests. This shows how we overwrite untracked ignored files when updating to a revision that tracks the file.
Wed, 03 Dec 2014 11:02:52 -0800 merge: don't overwrite conflicting file in locally renamed directory
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 11:02:52 -0800] rev 23476
merge: don't overwrite conflicting file in locally renamed directory When the local side has renamed a directory from a/ to b/ and added a file b/c in it, and the remote side has added a file a/c, we end up overwriting the local file b/c with the contents of remote file a/c. Add a check for this case and use the merge ('m') action in this case instead of the directory rename get ('dg') action.
Wed, 03 Dec 2014 10:56:07 -0800 merge: don't ignore conflicting file in remote renamed directory
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 10:56:07 -0800] rev 23475
merge: don't ignore conflicting file in remote renamed directory When the remote side has renamed a directory from a/ to b/ and added a file b/c in it, and the local side has added a file a/c, we end up moving a/c to b/c without considering the remote version of b/c. Add a check for this case and use the merge ('m') action in this case instead of the directory rename ('dm') action.
Sun, 23 Nov 2014 15:08:50 -0800 merge: duplicate 'if f in copied' into each branch
Martin von Zweigbergk <martinvonz@google.com> [Sun, 23 Nov 2014 15:08:50 -0800] rev 23474
merge: duplicate 'if f in copied' into each branch
Sun, 23 Nov 2014 14:09:10 -0800 merge: branch code into {n1 and n2, n1, n2} top-level cases
Martin von Zweigbergk <martinvonz@google.com> [Sun, 23 Nov 2014 14:09:10 -0800] rev 23473
merge: branch code into {n1 and n2, n1, n2} top-level cases There are three high-level cases that are of interest in manifestmerge(): 1) The file exists on both sides, 2) The file exists only on the local side, and 3) The file exists only on the remote side. Let's make this clearer in the code. The 'if f in copied' case will be broken up into the two applicable branches in the next patch.
Tue, 02 Dec 2014 16:39:59 -0800 update: remove redundant and misplaced merge tests
Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Dec 2014 16:39:59 -0800] rev 23472
update: remove redundant and misplaced merge tests The "nothing to merge" case is covered by test-merge-default.t. The "uncommitted changes" case is covered by test-merge1.t (and others). The "merge -f" case is covered by test-merge-force.t.
Fri, 21 Nov 2014 13:02:45 -0800 largefiles: use clearer debug messages in actions
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Nov 2014 13:02:45 -0800] rev 23471
largefiles: use clearer debug messages in actions In overridecalculateupdates(), 'g' (get) actions may be converted into other actions. In most of these cases, it does not make sense to keep the action's message. For example, 'remote created' does not make sense for an 'r' (remove) action.
Fri, 21 Nov 2014 11:44:57 -0800 largefiles: don't clobber merge action message with user message
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Nov 2014 11:44:57 -0800] rev 23470
largefiles: don't clobber merge action message with user message The message in the action is used for debugging and should not be the same as the question presented to the user. Use a different variable for the user message, so the 'msg' variable already in scope does not get overwritten.
Tue, 02 Dec 2014 20:31:19 -0800 bookmarks: factor out repository lookup from writing bookmarks file
Ryan McElroy <rmcelroy@fb.com> [Tue, 02 Dec 2014 20:31:19 -0800] rev 23469
bookmarks: factor out repository lookup from writing bookmarks file This will allow the share extension to extend bookmarks functionality to share bookmarks between repositories.
Thu, 04 Dec 2014 12:02:02 -0500 parsers: ensure revlog index node tree is initialized before insertion
Mike Edgar <adgar@google.com> [Thu, 04 Dec 2014 12:02:02 -0500] rev 23468
parsers: ensure revlog index node tree is initialized before insertion Currently, the revlog index C implementation assumes its node tree will be initialized before a new element is inserted by revnum. For example, revlog.py executes 'self.index.insert(-1, e)' in _addrevision(). This is only safe because the node tree has been initialized by a "node in self.nodemap" check made in addrevision(). (For context, this was discovered while developing an experimental revlog mixin which stores "elided nodes" via a separate code path from _addrevision(); that new code path segfaults without this patch.)
Wed, 03 Dec 2014 22:56:42 +0900 revset: add 'only' to DoS-safe symbols
Yuya Nishihara <yuya@tcha.org> [Wed, 03 Dec 2014 22:56:42 +0900] rev 23467
revset: add 'only' to DoS-safe symbols There is no reason to disable it in hgweb because the same query can be written without using 'only()'.
Wed, 03 Dec 2014 22:52:54 +0900 revset: move 'only' so that functions are sorted alphabetically
Yuya Nishihara <yuya@tcha.org> [Wed, 03 Dec 2014 22:52:54 +0900] rev 23466
revset: move 'only' so that functions are sorted alphabetically
Tue, 02 Dec 2014 22:42:41 -0500 tests: drop unnecessary glob that causes a warning on Windows
Matt Harbison <matt_harbison@yahoo.com> [Tue, 02 Dec 2014 22:42:41 -0500] rev 23465
tests: drop unnecessary glob that causes a warning on Windows This was triggered by 3778884197f0.
Wed, 03 Dec 2014 10:01:24 -0800 merge: add test with conflicting file and remote directory rename
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 10:01:24 -0800] rev 23464
merge: add test with conflicting file and remote directory rename Changset 88629daa727b (merge: demonstrate that directory renames can lose local file content, 2014-12-02) should clearly have added the reverse version of the test: where the remote side renamed a directory, added a new file in that directory, and the local directory added a conflicting file in the source directory. Add such a test now, and also touch up the ones already added slightly (e.g. 'local' was a stupid value for content that can be on either side of a merge).
Wed, 03 Dec 2014 15:03:29 -0800 graft: use a real conflict for the tests
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 15:03:29 -0800] rev 23463
graft: use a real conflict for the tests One of the graft tests grafts a changeset that changes a file's content from 'a' to 'b' onto a branch that has changed the file's content from 'a', via 'b', and then back to 'a' again. To prepare for not considering this a file in need of merging, let's use 'c' as the file's new content to make sure it has to be considered conflicting. There's a second similar case further down where an ancestor is grafted. Make sure that is also considered a conflict.
Wed, 03 Dec 2014 14:33:29 -0800 add: use lexists so that broken symbolic links are added
John Coomes <john.coomes@oracle.com> [Wed, 03 Dec 2014 14:33:29 -0800] rev 23462
add: use lexists so that broken symbolic links are added This restores the add behavior prior to d8cdd46f426d and matches the behavior of addremove.
Tue, 02 Dec 2014 05:12:59 +0100 rebase: avoid redundant repo[rev].rev() - just keep working in rev space
Mads Kiilerich <madski@unity3d.com> [Tue, 02 Dec 2014 05:12:59 +0100] rev 23461
rebase: avoid redundant repo[rev].rev() - just keep working in rev space
Tue, 02 Dec 2014 05:12:59 +0100 rebase: always store rev in state, also when collapsing
Mads Kiilerich <madski@unity3d.com> [Tue, 02 Dec 2014 05:12:59 +0100] rev 23460
rebase: always store rev in state, also when collapsing
Tue, 02 Dec 2014 05:12:53 +0100 rebase: clarify naming of variables holding node hashes - don't call them rev
Mads Kiilerich <madski@unity3d.com> [Tue, 02 Dec 2014 05:12:53 +0100] rev 23459
rebase: clarify naming of variables holding node hashes - don't call them rev
Thu, 27 Nov 2014 00:24:25 -0800 bookmarks: factor out bookmark file opening for easier extensibility
Ryan McElroy <rmcelroy@fb.com> [Thu, 27 Nov 2014 00:24:25 -0800] rev 23458
bookmarks: factor out bookmark file opening for easier extensibility
Tue, 02 Dec 2014 17:19:20 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 02 Dec 2014 17:19:20 -0600] rev 23457
merge with stable
Tue, 18 Nov 2014 22:18:05 -0800 diff: explicitly honor all diffopts
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 22:18:05 -0800] rev 23456
diff: explicitly honor all diffopts 'hg diff' should naturally honor all diffopts.
Tue, 18 Nov 2014 22:16:46 -0800 annotate: explicitly only honor whitespace diffopts
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 22:16:46 -0800] rev 23455
annotate: explicitly only honor whitespace diffopts The whitespace ones are the only ones the annotate logic cares about anyway, so there's no visible impact.
Tue, 18 Nov 2014 21:47:47 -0800 notify: explicitly honor all diffopts
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 21:47:47 -0800] rev 23454
notify: explicitly honor all diffopts The notify output doesn't seem to be parseable anyway, what with the maxdiff config option. Plus it is designed mainly for servers where hopefully the admins are doing sensible things.
Tue, 18 Nov 2014 22:13:05 -0800 jsonchangeset: don't honor whitespace and format-changing diffopts
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 22:13:05 -0800] rev 23453
jsonchangeset: don't honor whitespace and format-changing diffopts JSON is meant to be parsed by computers, and format changes can break them.
Tue, 18 Nov 2014 21:49:05 -0800 transplant: don't honor whitespace and format-changing diffopts
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 21:49:05 -0800] rev 23452
transplant: don't honor whitespace and format-changing diffopts transplant uses diff purely internally.
Tue, 18 Nov 2014 21:38:19 -0800 hgk: don't honor whitespace and format-changing diffopts
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 21:38:19 -0800] rev 23451
hgk: don't honor whitespace and format-changing diffopts The diff-tree command is a plumbing command in Git, which means it is expected to have a stable output format. Ensure that our output is stable too.
Tue, 18 Nov 2014 17:36:24 -0800 patchbomb: don't honor whitespace and format-changing diffopts (BC)
Siddharth Agarwal <sid0@fb.com> [Tue, 18 Nov 2014 17:36:24 -0800] rev 23450
patchbomb: don't honor whitespace and format-changing diffopts (BC) The whitespace diffopts break lossless transmission, and the format-changing ones make import harder. We expect parsers to be able to read git-style diffs, though.
Wed, 26 Nov 2014 11:45:21 -0800 merge: add more thorough tests for --force
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Nov 2014 11:45:21 -0800] rev 23449
merge: add more thorough tests for --force With generate-working-copy-states.py generalized to support arbitrarily many changesets, we can use it for generating test cases for merge: use one changeset each for base, remote and local. With the various working copy states, this is a total of 104 cases. The first candidate for additional testing is 'hg merge --force'. Even though the force option is deprecated, it is convenient for testing because it can be tested without first needing to revert any changes. Except for the lack of checking for uncommitted changes, it differs in only a few cases from unforced merge. The new tests cover all the cases in the existing test-merge-force.t, except for the unforced merge case, which is covered in several other files anyway, so nothing remains of the file after this patch.
Wed, 26 Nov 2014 10:25:27 -0800 merge: display modify/delete conflict prompts in sorted order
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Nov 2014 10:25:27 -0800] rev 23448
merge: display modify/delete conflict prompts in sorted order The order is determined by manifest.diff(), which currently is not sorted. There are currently no tests for this, but we will soon add some that would be flaky without this patch.
Sun, 09 Nov 2014 00:10:29 -0800 generate-working-copy-states: accept depth arguments on command line
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.
Sat, 08 Nov 2014 23:37:54 -0800 generate-working-copy-states: generalize for depth
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.
Sat, 29 Nov 2014 14:39:33 -0800 generate-working-copy-states: make 'tracked' a string
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.
Tue, 02 Dec 2014 13:28:07 -0800 merge: demonstrate that directory renames can lose local file content
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.
Fri, 28 Nov 2014 03:09:19 +0100 mq: drop updateheader - inserthgheader and insertplainheader is enough
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Nov 2014 03:09:19 +0100] rev 23443
mq: drop updateheader - inserthgheader and insertplainheader is enough
Fri, 28 Nov 2014 03:09:06 +0100 mq: smarter handling of plain headers
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.
Sun, 30 Nov 2014 23:30:31 -0500 largefiles: drop the override for 'fetch'
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.
Tue, 02 Dec 2014 11:06:38 -0800 rebase: ignore negative state when updating back to original wc parent stable
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.
Fri, 21 Nov 2014 15:50:38 -0800 bundle2-push: provide transaction to reply unbundler
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.
Mon, 24 Nov 2014 16:04:44 -0800 bundle2.processbundle: let callers request default behavior
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.
Fri, 21 Nov 2014 15:06:38 -0800 push: elevate phase transaction to cover entire operation
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.
Fri, 21 Nov 2014 14:32:57 -0800 pull: extract transaction logic into separate object
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.
Tue, 18 Nov 2014 20:00:37 -0800 record: don't honor format-changing diffopts (issue4459)
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.
Tue, 18 Nov 2014 17:22:03 -0800 patch.difffeatureopts: add a feature for format-changing diffopts
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.
Tue, 18 Nov 2014 17:09:26 -0800 patch.difffeatureopts: add a feature for whitespace diffopts
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.
Tue, 18 Nov 2014 17:10:14 -0800 patch.difffeatureopts: add a feature for diff.git
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.
Tue, 18 Nov 2014 21:43:38 -0800 patch: rename diffopts to diffallopts
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.
Tue, 18 Nov 2014 16:53:22 -0800 patch: add a new function to initialize diffopts by feature
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.
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
(0) -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 +10000 tip