facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-10 00:45:18 +03:00
Code Issues Projects Releases Wiki Activity
cb90ed6abe
sapling/tests/test-log.t

2500 lines
54 KiB
Perl
Raw Normal View History

test-helpers: add a helper to run test using chg Summary: The helper could be used in individual tests to enable chg if chg exists. This allows us to have more precise control on what tests to use chg instead of using a global flag in run-tests.py. This makes certain tests containing many hg commands much faster. For example, `test-revset.t` took 99 seconds before: % ./run-tests.py test-revset.t --time . # Ran 1 tests, 0 skipped, 0 failed. # Producing time report start end cuser csys real Test 0.000 99.990 86.410 12.000 99.990 test-revset.t And 10 seconds after: % ./run-tests.py test-revset.t --time . # Ran 1 tests, 0 skipped, 0 failed. # Producing time report start end cuser csys real Test 0.000 10.080 0.380 0.130 10.080 test-revset.t Also enable it for some other tests. Note the whitelist is not complete. We probably want to whitelist more tests in the future. The feature could be opted out by deleting `contrib/chg/chg`. Reviewed By: phillco Differential Revision: D6767036 fbshipit-source-id: 8220cf408aa198d5d8e2ca5127ca60e2070d3444
2018-01-23 23:09:16 +03:00
$ . helpers-usechg.sh
log: fix behavior with empty repositories (issue3497) Make output in this special case consistent with general case one.
2013-04-17 00:29:54 +04:00
Log on empty repository: checking consistency
$ hg init empty
$ cd empty
$ hg log
$ hg log -r 1
abort: unknown revision '1'!
[255]
$ hg log -r -1:0
abort: unknown revision '-1'!
[255]
$ hg log -r 'branch(name)'
abort: unknown revision 'name'!
[255]
$ hg log -r null -q
-1:000000000000
tests: change to parent directory before all "hg init" in test-log.t Add a "cd .." before the second "hg init" so that all repositories are on top level of test directory. Makes inspection of test directory easier.
2017-10-04 11:02:15 +03:00
$ cd ..
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
The g is crafted to have 2 filelog topological heads in a linear
changeset graph
tests: unify test-log
2010-08-15 18:34:46 +04:00
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
$ hg init a
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ cd a
$ echo a > a
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
$ echo f > f
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg ci -Ama -d '1 0'
adding a
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
adding f
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg cp a b
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
$ hg cp f g
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg ci -mb -d '2 0'
$ mkdir dir
$ hg mv b dir
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
$ echo g >> g
$ echo f >> f
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg ci -mc -d '3 0'
$ hg mv a b
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
$ hg cp -f f g
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ echo a > d
$ hg add d
$ hg ci -md -d '4 0'
$ hg mv dir/b e
$ hg ci -me -d '5 0'
largefiles: remove the extension Summary: `lfs` is the better large file solution. `largefiles` is rarely used, and its implementation is less clean. So let's remove it. Test Plan: Ran all tests. A subrepo test was removed instead of cleaned up since the longer term plan is to also drop subrepo support. Reviewers: phillco, #mercurial Reviewed By: phillco Differential Revision: https://phabricator.intern.facebook.com/D6740361 Signature: 6740361:1516225594:555e3803571ad05e0434021897a2823ac99347ae
2018-01-17 22:50:44 +03:00
$ hg --debug log a -T '{rev}: {desc}\n'
largefiles: don't prefix standin patterns with '.hglf' when logging When logging '.hglf/foo', the pattern list was being transformed from ['.hglf/foo'] into ['.hglf/foo', '.hglf/.hglf/foo']. Aside from the pathological case of somebody getting a directory named '.hglf' created inside the standing directory, the old code shouldn't have had any bad effects. (amended by mpm to sort patterns for test stability and not upset check-code)
2015-03-01 22:21:54 +03:00
0: a
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg log a
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 0:9161b9aeaf16
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: a
largefiles: teach log to handle patterns Adding the standin to the patterns list was (possibly) harmless before, but was wrong, because the pattern list was already updated above that code. Now that patterns are handled, it was actually harmful. For example, in this test: $ hg log -G glob:**another* the adjusted pattern list would have been: ['glob:**another*', '.hglf/.', 'glob:.hglf/**another*'] which causes every largefile in the root to be matched. I'm not sure why 'glob:a*' picks up the rename of a -> b commit in test-log.t, but a simple 'a' doesn't. But it doesn't appear to be caused by the largefiles extension.
2015-03-01 07:42:38 +03:00
$ hg log glob:a*
changeset: 3:2ca5ba701980
user: test
date: Thu Jan 01 00:00:04 1970 +0000
summary: d
changeset: 0:9161b9aeaf16
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: a
largefiles: remove the extension Summary: `lfs` is the better large file solution. `largefiles` is rarely used, and its implementation is less clean. So let's remove it. Test Plan: Ran all tests. A subrepo test was removed instead of cleaned up since the longer term plan is to also drop subrepo support. Reviewers: phillco, #mercurial Reviewed By: phillco Differential Revision: https://phabricator.intern.facebook.com/D6740361 Signature: 6740361:1516225594:555e3803571ad05e0434021897a2823ac99347ae
2018-01-17 22:50:44 +03:00
$ hg --debug log glob:a* -T '{rev}: {desc}\n'
largefiles: don't prefix standin patterns with '.hglf' when logging When logging '.hglf/foo', the pattern list was being transformed from ['.hglf/foo'] into ['.hglf/foo', '.hglf/.hglf/foo']. Aside from the pathological case of somebody getting a directory named '.hglf' created inside the standing directory, the old code shouldn't have had any bad effects. (amended by mpm to sort patterns for test stability and not upset check-code)
2015-03-01 22:21:54 +03:00
3: d
0: a
log: make log work even if first parameter doesn't exist A slowpath optimization kicked in too often because of wrong indentation.
2013-01-15 04:05:12 +04:00
log on directory
$ hg log dir
changeset: 4:7e4639b4691b
tag: tip
user: test
date: Thu Jan 01 00:00:05 1970 +0000
summary: e
changeset: 2:f8954cd4dc1f
user: test
date: Thu Jan 01 00:00:03 1970 +0000
summary: c
$ hg log somethingthatdoesntexist dir
changeset: 4:7e4639b4691b
tag: tip
user: test
date: Thu Jan 01 00:00:05 1970 +0000
summary: e
changeset: 2:f8954cd4dc1f
user: test
date: Thu Jan 01 00:00:03 1970 +0000
summary: c
tests: unify test-log
2010-08-15 18:34:46 +04:00
log: allow patterns with -f It's not uncommon for a user to want to run log with a pattern or directory name on the history of their current commit. Currently we prevent that, but I can't think of any reason to continue blocking that. This commit removes the restriction and allows 'hg log -f <dir/pat>'
2014-07-23 09:40:16 +04:00
-f, non-existent directory
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg log -f dir
log: fix --follow FILE ancestry calculation Currently, --follow FILE looks for a FILE filelog, scans it and collects linkrevs and renames, then filters them. The problem is the filelog scan does not start at FILE filenode in parent revision but at the last filelog revision. So: - Files not in the parent revision can be followed, the starting node is unexpected - Files in the parent revision can be followed from an incorrect starting node. This patch makes log --follow FILE fail if FILE is not in parent revision, and computes ancestors of the parent revision FILE filenode.
2012-02-24 23:57:59 +04:00
abort: cannot follow file not in parent revision: "dir"
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-log
2010-08-15 18:34:46 +04:00
log: allow patterns with -f It's not uncommon for a user to want to run log with a pattern or directory name on the history of their current commit. Currently we prevent that, but I can't think of any reason to continue blocking that. This commit removes the restriction and allows 'hg log -f <dir/pat>'
2014-07-23 09:40:16 +04:00
-f, directory
$ hg up -q 3
$ hg log -f dir
changeset: 2:f8954cd4dc1f
user: test
date: Thu Jan 01 00:00:03 1970 +0000
summary: c
-f, directory with --patch
$ hg log -f dir -p
changeset: 2:f8954cd4dc1f
user: test
date: Thu Jan 01 00:00:03 1970 +0000
summary: c
diff -r d89b0a12d229 -r f8954cd4dc1f dir/b
--- /dev/null* (glob)
+++ b/dir/b* (glob)
@@ -0,0 +1,1 @@
+a
-f, pattern
$ hg log -f -I 'dir**' -p
changeset: 2:f8954cd4dc1f
user: test
date: Thu Jan 01 00:00:03 1970 +0000
summary: c
diff -r d89b0a12d229 -r f8954cd4dc1f dir/b
--- /dev/null* (glob)
+++ b/dir/b* (glob)
@@ -0,0 +1,1 @@
+a
$ hg up -q 4
templater: show the style list when I try to use a wrong one When someone try to use a wrong style, a list with sugestions will appear. In the test-log.t file it's a test that prove this thing.
2013-05-03 05:23:14 +04:00
-f, a wrong style
$ hg log -f -l1 --style something
abort: style 'something' not found
show: new extension for displaying various repository data Currently, Mercurial has a number of commands to show information. And, there are features coming down the pipe that will introduce more commands for showing information. Currently, when introducing a new class of data or a view that we wish to expose to the user, the strategy is to introduce a new command or overload an existing command, sometimes both. For example, there is a desire to formalize the wip/smartlog/underway/mine functionality that many have devised. There is also a desire to introduce a "topics" concept. Others would like views of "the current stack." In the current model, we'd need a new command for wip/smartlog/etc (that behaves a lot like a pre-defined alias of `hg log`). For topics, we'd likely overload `hg topic[s]` to both display and manipulate topics. Adding new commands for every pre-defined query doesn't scale well and pollutes `hg help`. Overloading commands to perform read-only and write operations is arguably an UX anti-pattern: while having all functionality for a given concept in one command is nice, having a single command doing multiple discrete operations is not. Furthermore, a user may be surprised that a command they thought was read-only actually changes something. We discussed this at the Mercurial 4.0 Sprint in Paris and decided that having a single command where we could hang pre-defined views of various data would be a good idea. Having such a command would: * Help prevent an explosion of new query-related commands * Create a clear separation between read and write operations (mitigates footguns) * Avoids overloading the meaning of commands that manipulate data (bookmark, tag, branch, etc) (while we can't take away the existing behavior for BC reasons, we now won't introduce this behavior on new commands) * Allows users to discover informational views more easily by aggregating them in a single location * Lowers the barrier to creating the new views (since the barrier to creating a top-level command is relatively high) So, this commit introduces the `hg show` command via the "show" extension. This command accepts a positional argument of the "view" to show. New views can be registered with a decorator. To prove it works, we implement the "bookmarks" view, which shows a table of bookmarks and their associated nodes. We introduce a new style to hold everything used by `hg show`. For our initial bookmarks view, the output varies from `hg bookmarks`: * Padding is performed in the template itself as opposed to Python * Revision integers are not shown * shortest() is used to display a 5 character node by default (as opposed to static 12 characters) I chose to implement the "bookmarks" view first because it is simple and shouldn't invite too much bikeshedding that detracts from the evaluation of `hg show` itself. But there is an important point to consider: we now have 2 ways to show a list of bookmarks. I'm not a fan of introducing multiple ways to do very similar things. So it might be worth discussing how we wish to tackle this issue for bookmarks, tags, branches, MQ series, etc. I also made the choice of explicitly declaring the default show template not part of the standard BC guarantees. History has shown that we make mistakes and poor choices with output formatting but can't fix these mistakes later because random tools are parsing output and we don't want to break these tools. Optimizing for human consumption is one of my goals for `hg show`. So, by not covering the formatting as part of BC, the barrier to future change is much lower and humans benefit. There are some improvements that can be made to formatting. For example, we don't yet use label() in the templates. We obviously want this for color. But I'm not sure if we should reuse the existing log.* labels or invent new ones. I figure we can punt that to a follow-up. At the aforementioned Sprint, we discussed and discarded various alternatives to `hg show`. We considered making `hg log <view>` perform this behavior. The main reason we can't do this is because a positional argument to `hg log` can be a file path and if there is a conflict between a path name and a view name, behavior is ambiguous. We could have introduced `hg log --view` or similar, but we felt that required too much typing (we don't want to require a command flag to show a view) and wasn't very discoverable. Furthermore, `hg log` is optimized for showing changelog data and there are things that `hg display` could display that aren't changelog centric. There were concerns about using "show" as the command name. Some users already have a "show" alias that is similar to `hg export`. There were also concerns that Git users adapted to `git show` would be confused by `hg show`'s different behavior. The main difference here is `git show` prints an `hg export` like view of the current commit by default and `hg show` requires an argument. `git show` can also display any Git object. `git show` does not support displaying more complex views: just single objects. If we implemented `hg show <hash>` or `hg show <identifier>`, `hg show` would be a superset of `git show`. Although, I'm hesitant to do that at this time because I view `hg show` as a higher-level querying command and there are namespace collisions between valid identifiers and registered views. There is also a prefix collision with `hg showconfig`, which is an alias of `hg config`. We also considered `hg view`, but that is already used by the "hgk" extension. `hg display` was also proposed at one point. It has a prefix collision with `hg diff`. General consensus was "show" or "view" are the best verbs. And since "view" was taken, "show" was chosen. There are a number of inline TODOs in this patch. Some of these represent decisions yet to be made. Others represent features requiring non-trivial complexity. Rather than bloat the patch or invite additional bikeshedding, I figured I'd document future enhancements via TODO so we can get a minimal implmentation landed. Something is better than nothing.
2017-03-25 05:19:00 +03:00
(available styles: bisect, changelog, compact, default, phases, show, status, xml)
templater: show the style list when I try to use a wrong one When someone try to use a wrong style, a list with sugestions will appear. In the test-log.t file it's a test that prove this thing.
2013-05-03 05:23:14 +04:00
[255]
log-style: add a log style that is default+phase (issue3436) There is a new style called phases style. Usage:: hg log --style phases Why do we need this new style - in what way is it different from or similar to existing styles? The new style is default + phases information. With the new phases feature the users exhibited their desire for a new style that could help them. Why do this need a new style - couldn't it be folded into an existing style? The default style and the new one are about the same, the difference is the phases tag. The users find both styles useful, this means that the both styles must exist.
2013-04-18 23:56:57 +04:00
-f, phases style
$ hg log -f -l1 --style phases
changeset: 4:7e4639b4691b
tag: tip
phase: draft
user: test
date: Thu Jan 01 00:00:05 1970 +0000
summary: e
templater: show the style list when I try to use a wrong one When someone try to use a wrong style, a list with sugestions will appear. In the test-log.t file it's a test that prove this thing.
2013-05-03 05:23:14 +04:00
templates: fix "log -q" output of phases style It had the same problem as be4dab229c78, name conflicts of {node} keyword.
2015-03-28 14:22:03 +03:00
$ hg log -f -l1 --style phases -q
4:7e4639b4691b
tests: unify test-log
2010-08-15 18:34:46 +04:00
-f, but no args
$ hg log -f
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 4:7e4639b4691b
tests: unify test-log
2010-08-15 18:34:46 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:05 1970 +0000
summary: e
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 3:2ca5ba701980
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:04 1970 +0000
summary: d
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 2:f8954cd4dc1f
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:03 1970 +0000
summary: c
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 1:d89b0a12d229
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:02 1970 +0000
summary: b
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 0:9161b9aeaf16
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: a
one rename
log: fix --follow FILE ancestry calculation Currently, --follow FILE looks for a FILE filelog, scans it and collects linkrevs and renames, then filters them. The problem is the filelog scan does not start at FILE filenode in parent revision but at the last filelog revision. So: - Files not in the parent revision can be followed, the starting node is unexpected - Files in the parent revision can be followed from an incorrect starting node. This patch makes log --follow FILE fail if FILE is not in parent revision, and computes ancestors of the parent revision FILE filenode.
2012-02-24 23:57:59 +04:00
$ hg up -q 2
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg log -vf a
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 0:9161b9aeaf16
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: a f
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
a
many renames
log: fix --follow FILE ancestry calculation Currently, --follow FILE looks for a FILE filelog, scans it and collects linkrevs and renames, then filters them. The problem is the filelog scan does not start at FILE filenode in parent revision but at the last filelog revision. So: - Files not in the parent revision can be followed, the starting node is unexpected - Files in the parent revision can be followed from an incorrect starting node. This patch makes log --follow FILE fail if FILE is not in parent revision, and computes ancestors of the parent revision FILE filenode.
2012-02-24 23:57:59 +04:00
$ hg up -q tip
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg log -vf e
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 4:7e4639b4691b
tests: unify test-log
2010-08-15 18:34:46 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:05 1970 +0000
files: dir/b e
description:
e
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 2:f8954cd4dc1f
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:03 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: b dir/b f g
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
c
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 1:d89b0a12d229
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:02 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: b g
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
b
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 0:9161b9aeaf16
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: a f
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
a
log -pf dir/b
log: fix --follow FILE ancestry calculation Currently, --follow FILE looks for a FILE filelog, scans it and collects linkrevs and renames, then filters them. The problem is the filelog scan does not start at FILE filenode in parent revision but at the last filelog revision. So: - Files not in the parent revision can be followed, the starting node is unexpected - Files in the parent revision can be followed from an incorrect starting node. This patch makes log --follow FILE fail if FILE is not in parent revision, and computes ancestors of the parent revision FILE filenode.
2012-02-24 23:57:59 +04:00
$ hg up -q 3
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg log -pf dir/b
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 2:f8954cd4dc1f
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:03 1970 +0000
summary: c
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
diff -r d89b0a12d229 -r f8954cd4dc1f dir/b
tests: unify test-log
2010-08-15 18:34:46 +04:00
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dir/b Thu Jan 01 00:00:03 1970 +0000
@@ -0,0 +1,1 @@
+a
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 1:d89b0a12d229
log: make --patch --follow work inside a subdirectory Previously, the 'patch' code for hg log --patch --follow would try to resolve patterns relative to the repository root rather than the current working directory. Fix that by using match.files instead of pats, as done elsewhere nearby.
2014-07-12 13:23:17 +04:00
user: test
date: Thu Jan 01 00:00:02 1970 +0000
summary: b
diff -r 9161b9aeaf16 -r d89b0a12d229 b
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/b Thu Jan 01 00:00:02 1970 +0000
@@ -0,0 +1,1 @@
+a
changeset: 0:9161b9aeaf16
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: a
diff -r 000000000000 -r 9161b9aeaf16 a
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/a Thu Jan 01 00:00:01 1970 +0000
@@ -0,0 +1,1 @@
+a
log -pf b inside dir
$ hg --cwd=dir log -pf b
changeset: 2:f8954cd4dc1f
user: test
date: Thu Jan 01 00:00:03 1970 +0000
summary: c
diff -r d89b0a12d229 -r f8954cd4dc1f dir/b
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dir/b Thu Jan 01 00:00:03 1970 +0000
tests: unify test-log
2010-08-15 18:34:46 +04:00
@@ -0,0 +1,1 @@
+a
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 1:d89b0a12d229
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:02 1970 +0000
summary: b
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
diff -r 9161b9aeaf16 -r d89b0a12d229 b
tests: unify test-log
2010-08-15 18:34:46 +04:00
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/b Thu Jan 01 00:00:02 1970 +0000
@@ -0,0 +1,1 @@
+a
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 0:9161b9aeaf16
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: a
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
diff -r 000000000000 -r 9161b9aeaf16 a
tests: unify test-log
2010-08-15 18:34:46 +04:00
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/a Thu Jan 01 00:00:01 1970 +0000
@@ -0,0 +1,1 @@
+a
log: do not use exact matcher for --patch --follow without file (issue4319) 5d9f39626224 is valid only if file argument is specified. If no pattern specified, it can simply fall back to the original matcher.
2014-08-01 16:36:56 +04:00
log -pf, but no args
$ hg log -pf
changeset: 3:2ca5ba701980
user: test
date: Thu Jan 01 00:00:04 1970 +0000
summary: d
diff -r f8954cd4dc1f -r 2ca5ba701980 a
--- a/a Thu Jan 01 00:00:03 1970 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +0,0 @@
-a
diff -r f8954cd4dc1f -r 2ca5ba701980 b
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/b Thu Jan 01 00:00:04 1970 +0000
@@ -0,0 +1,1 @@
+a
diff -r f8954cd4dc1f -r 2ca5ba701980 d
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/d Thu Jan 01 00:00:04 1970 +0000
@@ -0,0 +1,1 @@
+a
diff -r f8954cd4dc1f -r 2ca5ba701980 g
--- a/g Thu Jan 01 00:00:03 1970 +0000
+++ b/g Thu Jan 01 00:00:04 1970 +0000
@@ -1,2 +1,2 @@
f
-g
+f
changeset: 2:f8954cd4dc1f
user: test
date: Thu Jan 01 00:00:03 1970 +0000
summary: c
diff -r d89b0a12d229 -r f8954cd4dc1f b
--- a/b Thu Jan 01 00:00:02 1970 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +0,0 @@
-a
diff -r d89b0a12d229 -r f8954cd4dc1f dir/b
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dir/b Thu Jan 01 00:00:03 1970 +0000
@@ -0,0 +1,1 @@
+a
diff -r d89b0a12d229 -r f8954cd4dc1f f
--- a/f Thu Jan 01 00:00:02 1970 +0000
+++ b/f Thu Jan 01 00:00:03 1970 +0000
@@ -1,1 +1,2 @@
f
+f
diff -r d89b0a12d229 -r f8954cd4dc1f g
--- a/g Thu Jan 01 00:00:02 1970 +0000
+++ b/g Thu Jan 01 00:00:03 1970 +0000
@@ -1,1 +1,2 @@
f
+g
changeset: 1:d89b0a12d229
user: test
date: Thu Jan 01 00:00:02 1970 +0000
summary: b
diff -r 9161b9aeaf16 -r d89b0a12d229 b
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/b Thu Jan 01 00:00:02 1970 +0000
@@ -0,0 +1,1 @@
+a
diff -r 9161b9aeaf16 -r d89b0a12d229 g
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/g Thu Jan 01 00:00:02 1970 +0000
@@ -0,0 +1,1 @@
+f
changeset: 0:9161b9aeaf16
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: a
diff -r 000000000000 -r 9161b9aeaf16 a
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/a Thu Jan 01 00:00:01 1970 +0000
@@ -0,0 +1,1 @@
+a
diff -r 000000000000 -r 9161b9aeaf16 f
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/f Thu Jan 01 00:00:01 1970 +0000
@@ -0,0 +1,1 @@
+f
tests: unify test-log
2010-08-15 18:34:46 +04:00
log -vf dir/b
$ hg log -vf dir/b
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 2:f8954cd4dc1f
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:03 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: b dir/b f g
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
c
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 1:d89b0a12d229
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:02 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: b g
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
b
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 0:9161b9aeaf16
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: a f
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
a
log: fix --follow FILE ancestry calculation Currently, --follow FILE looks for a FILE filelog, scans it and collects linkrevs and renames, then filters them. The problem is the filelog scan does not start at FILE filenode in parent revision but at the last filelog revision. So: - Files not in the parent revision can be followed, the starting node is unexpected - Files in the parent revision can be followed from an incorrect starting node. This patch makes log --follow FILE fail if FILE is not in parent revision, and computes ancestors of the parent revision FILE filenode.
2012-02-24 23:57:59 +04:00
-f and multiple filelog heads
$ hg up -q 2
$ hg log -f g --template '{rev}\n'
2
1
0
$ hg up -q tip
$ hg log -f g --template '{rev}\n'
3
2
0
tests: unify test-log
2010-08-15 18:34:46 +04:00
log copies with --copies
$ hg log -vC --template '{rev} {file_copies}\n'
4 e (dir/b)
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
3 b (a)g (f)
tests: unify test-log
2010-08-15 18:34:46 +04:00
2 dir/b (b)
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
1 b (a)g (f)
tests: unify test-log
2010-08-15 18:34:46 +04:00
0
log copies switch without --copies, with old filecopy template
$ hg log -v --template '{rev} {file_copies_switch%filecopy}\n'
4
3
2
1
0
log copies switch with --copies
$ hg log -vC --template '{rev} {file_copies_switch}\n'
4 e (dir/b)
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
3 b (a)g (f)
tests: unify test-log
2010-08-15 18:34:46 +04:00
2 dir/b (b)
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
1 b (a)g (f)
tests: unify test-log
2010-08-15 18:34:46 +04:00
0
log copies with hardcoded style and with --style=default
$ hg log -vC -r4
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 4:7e4639b4691b
tests: unify test-log
2010-08-15 18:34:46 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:05 1970 +0000
files: dir/b e
copies: e (dir/b)
description:
e
$ hg log -vC -r4 --style=default
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 4:7e4639b4691b
tests: unify test-log
2010-08-15 18:34:46 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:05 1970 +0000
files: dir/b e
copies: e (dir/b)
description:
e
log: fix json-formatted output when file copies are listed (issue4523)
2015-02-02 22:26:47 +03:00
$ hg log -vC -r4 -Tjson
[
{
"rev": 4,
"node": "7e4639b4691b9f84b81036a8d4fb218ce3c5e3a3",
"branch": "default",
"phase": "draft",
"user": "test",
"date": [5, 0],
"desc": "e",
"bookmarks": [],
"tags": ["tip"],
"parents": ["2ca5ba7019804f1f597249caddf22a64d34df0ba"],
"files": ["dir/b", "e"],
"copies": {"e": "dir/b"}
}
]
tests: unify test-log
2010-08-15 18:34:46 +04:00
log copies, non-linear manifest
$ hg up -C 3
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg mv dir/b e
$ echo foo > foo
$ hg ci -Ame2 -d '6 0'
adding foo
$ hg log -v --template '{rev} {file_copies}\n' -r 5
5 e (dir/b)
log copies, execute bit set
test-log: enable for Windows
2012-06-08 17:11:05 +04:00
#if execbit
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ chmod +x e
$ hg ci -me3 -d '7 0'
$ hg log -v --template '{rev} {file_copies}\n' -r 6
6
test-log: enable for Windows
2012-06-08 17:11:05 +04:00
#endif
tests: unify test-log
2010-08-15 18:34:46 +04:00
log -p d
$ hg log -pv d
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 3:2ca5ba701980
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:04 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: a b d g
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
d
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
diff -r f8954cd4dc1f -r 2ca5ba701980 d
tests: unify test-log
2010-08-15 18:34:46 +04:00
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/d Thu Jan 01 00:00:04 1970 +0000
@@ -0,0 +1,1 @@
+a
log --removed file
$ hg log --removed -v a
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 3:2ca5ba701980
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:04 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: a b d g
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
d
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 0:9161b9aeaf16
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: a f
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
a
log --removed revrange file
$ hg log --removed -v -r0:2 a
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
changeset: 0:9161b9aeaf16
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
2012-02-24 23:56:18 +04:00
files: a f
tests: unify test-log
2010-08-15 18:34:46 +04:00
description:
a
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
$ cd ..
tests: unify test-log
2010-08-15 18:34:46 +04:00
log --follow tests
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
$ hg init follow
$ cd follow
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ echo base > base
$ hg ci -Ambase -d '1 0'
adding base
$ echo r1 >> base
$ hg ci -Amr1 -d '1 0'
$ echo r2 >> base
$ hg ci -Amr2 -d '1 0'
$ hg up -C 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo b1 > b1
revsets: makes follow() supports file patterns (issue4757) (BC) Before this patch, follow only supports full, exact filenames. This patch makes follow argument to be treated like file pattern same way like log treats their arguments. It preserves current behaviour of follow() matching paths relative to the repository root by default.
2015-08-20 18:19:32 +03:00
log -r "follow('set:clean()')"
$ hg log -r "follow('set:clean()')"
changeset: 0:67e992f2c4f3
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: base
changeset: 1:3d5bf5654eda
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: r1
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg ci -Amb1 -d '1 0'
adding b1
log -f
$ hg log -f
changeset: 3:e62f78d544b4
tag: tip
parent: 1:3d5bf5654eda
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b1
changeset: 1:3d5bf5654eda
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: r1
changeset: 0:67e992f2c4f3
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: base
revsets: makes follow() supports file patterns (issue4757) (BC) Before this patch, follow only supports full, exact filenames. This patch makes follow argument to be treated like file pattern same way like log treats their arguments. It preserves current behaviour of follow() matching paths relative to the repository root by default.
2015-08-20 18:19:32 +03:00
log -r follow('glob:b*')
tests: unify test-log
2010-08-15 18:34:46 +04:00
revsets: makes follow() supports file patterns (issue4757) (BC) Before this patch, follow only supports full, exact filenames. This patch makes follow argument to be treated like file pattern same way like log treats their arguments. It preserves current behaviour of follow() matching paths relative to the repository root by default.
2015-08-20 18:19:32 +03:00
$ hg log -r "follow('glob:b*')"
changeset: 0:67e992f2c4f3
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: base
changeset: 1:3d5bf5654eda
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: r1
changeset: 3:e62f78d544b4
tag: tip
parent: 1:3d5bf5654eda
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b1
log: make -fr show complete history from the given revs Right now it's very obtuse to show the history of a particular rev (hg log -r 'reverse(::foo)'). This changes the -f option to make it follow history for the revs specified by -r. The current -f -r behavior is to limit the result of -r to only the commits that are ancestors of the current working copy. Changing this is a bit of a BC break, but the old behavior is A) rare, B) easy to emulate (& ::.), and C) currently undefined. The new behavior is frequently requested enough that I think the change is worth it.
2015-02-06 22:04:55 +03:00
log -f -r '1 + 4'
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg up -C 0
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo b2 > b2
$ hg ci -Amb2 -d '1 0'
adding b2
log: make -fr show complete history from the given revs Right now it's very obtuse to show the history of a particular rev (hg log -r 'reverse(::foo)'). This changes the -f option to make it follow history for the revs specified by -r. The current -f -r behavior is to limit the result of -r to only the commits that are ancestors of the current working copy. Changing this is a bit of a BC break, but the old behavior is A) rare, B) easy to emulate (& ::.), and C) currently undefined. The new behavior is frequently requested enough that I think the change is worth it.
2015-02-06 22:04:55 +03:00
$ hg log -f -r '1 + 4'
changeset: 4:ddb82e70d1a1
tag: tip
parent: 0:67e992f2c4f3
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
log: make -fr show complete history from the given revs Right now it's very obtuse to show the history of a particular rev (hg log -r 'reverse(::foo)'). This changes the -f option to make it follow history for the revs specified by -r. The current -f -r behavior is to limit the result of -r to only the commits that are ancestors of the current working copy. Changing this is a bit of a BC break, but the old behavior is A) rare, B) easy to emulate (& ::.), and C) currently undefined. The new behavior is frequently requested enough that I think the change is worth it.
2015-02-06 22:04:55 +03:00
summary: b2
tests: unify test-log
2010-08-15 18:34:46 +04:00
log: make -fr show complete history from the given revs Right now it's very obtuse to show the history of a particular rev (hg log -r 'reverse(::foo)'). This changes the -f option to make it follow history for the revs specified by -r. The current -f -r behavior is to limit the result of -r to only the commits that are ancestors of the current working copy. Changing this is a bit of a BC break, but the old behavior is A) rare, B) easy to emulate (& ::.), and C) currently undefined. The new behavior is frequently requested enough that I think the change is worth it.
2015-02-06 22:04:55 +03:00
changeset: 1:3d5bf5654eda
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
log: make -fr show complete history from the given revs Right now it's very obtuse to show the history of a particular rev (hg log -r 'reverse(::foo)'). This changes the -f option to make it follow history for the revs specified by -r. The current -f -r behavior is to limit the result of -r to only the commits that are ancestors of the current working copy. Changing this is a bit of a BC break, but the old behavior is A) rare, B) easy to emulate (& ::.), and C) currently undefined. The new behavior is frequently requested enough that I think the change is worth it.
2015-02-06 22:04:55 +03:00
summary: r1
tests: unify test-log
2010-08-15 18:34:46 +04:00
log: make -fr show complete history from the given revs Right now it's very obtuse to show the history of a particular rev (hg log -r 'reverse(::foo)'). This changes the -f option to make it follow history for the revs specified by -r. The current -f -r behavior is to limit the result of -r to only the commits that are ancestors of the current working copy. Changing this is a bit of a BC break, but the old behavior is A) rare, B) easy to emulate (& ::.), and C) currently undefined. The new behavior is frequently requested enough that I think the change is worth it.
2015-02-06 22:04:55 +03:00
changeset: 0:67e992f2c4f3
tests: unify test-log
2010-08-15 18:34:46 +04:00
user: test
date: Thu Jan 01 00:00:01 1970 +0000
log: make -fr show complete history from the given revs Right now it's very obtuse to show the history of a particular rev (hg log -r 'reverse(::foo)'). This changes the -f option to make it follow history for the revs specified by -r. The current -f -r behavior is to limit the result of -r to only the commits that are ancestors of the current working copy. Changing this is a bit of a BC break, but the old behavior is A) rare, B) easy to emulate (& ::.), and C) currently undefined. The new behavior is frequently requested enough that I think the change is worth it.
2015-02-06 22:04:55 +03:00
summary: base
tests: unify test-log
2010-08-15 18:34:46 +04:00
revsets: makes follow() supports file patterns (issue4757) (BC) Before this patch, follow only supports full, exact filenames. This patch makes follow argument to be treated like file pattern same way like log treats their arguments. It preserves current behaviour of follow() matching paths relative to the repository root by default.
2015-08-20 18:19:32 +03:00
log -r "follow('set:grep(b2)')"
$ hg log -r "follow('set:grep(b2)')"
changeset: 4:ddb82e70d1a1
tag: tip
parent: 0:67e992f2c4f3
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b2
revset: support "follow(renamed.py, e22f4f3f06c3)" (issue5334) v2: fixes from review
2016-08-18 18:25:10 +03:00
log -r "follow('set:grep(b2)', 4)"
$ hg up -qC 0
$ hg log -r "follow('set:grep(b2)', 4)"
changeset: 4:ddb82e70d1a1
tag: tip
parent: 0:67e992f2c4f3
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b2
revset: make follow() accept multiple startrevs The diff might look slightly complicated, but the initial "c = repo['.']" was effective if rev = None.
2016-09-22 13:11:26 +03:00
follow files starting from multiple revisions:
revset: make follow() accept keyword arguments Also renamed the argument from 'pattern' to 'file' conforming to followlines().
2016-09-22 13:35:36 +03:00
$ hg log -T '{rev}: {files}\n' -r "follow('glob:b?', startrev=2+3+4)"
revset: make follow() accept multiple startrevs The diff might look slightly complicated, but the initial "c = repo['.']" was effective if rev = None.
2016-09-22 13:11:26 +03:00
3: b1
4: b2
follow files starting from empty revision:
revset: make follow() accept keyword arguments Also renamed the argument from 'pattern' to 'file' conforming to followlines().
2016-09-22 13:35:36 +03:00
$ hg log -T '{rev}: {files}\n' -r "follow('glob:*', startrev=.-.)"
revset: make follow() accept multiple startrevs The diff might look slightly complicated, but the initial "c = repo['.']" was effective if rev = None.
2016-09-22 13:11:26 +03:00
revset: make follow() accept keyword arguments Also renamed the argument from 'pattern' to 'file' conforming to followlines().
2016-09-22 13:35:36 +03:00
follow starting from revisions:
$ hg log -Gq -r "follow(startrev=2+4)"
revset: alias follow(startrev=rev) to ancestors(rev) This seems natural given 'log -frREV' (with no file pattern) is equivalent to 'log -frREV *'.
2016-09-22 13:40:07 +03:00
o 4:ddb82e70d1a1
|
| o 2:60c670bf5b30
| |
| o 1:3d5bf5654eda
|/
@ 0:67e992f2c4f3
follow the current revision:
$ hg log -Gq -r "follow()"
@ 0:67e992f2c4f3
revset: make follow() accept keyword arguments Also renamed the argument from 'pattern' to 'file' conforming to followlines().
2016-09-22 13:35:36 +03:00
revset: support "follow(renamed.py, e22f4f3f06c3)" (issue5334) v2: fixes from review
2016-08-18 18:25:10 +03:00
$ hg up -qC 4
revset: fix ancestors(null) to include null revision (issue4512) Since fe39bbbf31f0, null parent is explicitly excluded. So, there is no reason to have nullrev in the initial seen set.
2015-01-25 14:20:27 +03:00
log -f -r null
$ hg log -f -r null
changeset: -1:000000000000
user:
date: Thu Jan 01 00:00:00 1970 +0000
$ hg log -f -r null -G
o changeset: -1:000000000000
user:
date: Thu Jan 01 00:00:00 1970 +0000
log: fix --follow null parent not to include revision 0 If p1 is null, ':.' is translated as '0:null'. But rangeset can't handle null, only revision 0 was visible. Because 'null' should not be listed implicitly, "log --follow" (without -r) should be empty if p1 is null. Test of "hg grep -f" is added for cmdutil.walkchangerevs().
2015-02-06 15:53:39 +03:00
log -f with null parent
$ hg up -C null
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ hg log -f
tests: unify test-log
2010-08-15 18:34:46 +04:00
log -r . with two parents
$ hg up -C 3
log: fix --follow null parent not to include revision 0 If p1 is null, ':.' is translated as '0:null'. But rangeset can't handle null, only revision 0 was visible. Because 'null' should not be listed implicitly, "log --follow" (without -r) should be empty if p1 is null. Test of "hg grep -f" is added for cmdutil.walkchangerevs().
2015-02-06 15:53:39 +03:00
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg merge tip
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg log -r .
changeset: 3:e62f78d544b4
parent: 1:3d5bf5654eda
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b1
log -r . with one parent
$ hg ci -mm12 -d '1 0'
$ hg log -r .
changeset: 5:302e9dd6890d
tag: tip
parent: 3:e62f78d544b4
parent: 4:ddb82e70d1a1
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: m12
$ echo postm >> b1
$ hg ci -Amb1.1 -d'1 0'
log --follow-first
$ hg log --follow-first
changeset: 6:2404bbcab562
tag: tip
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b1.1
changeset: 5:302e9dd6890d
parent: 3:e62f78d544b4
parent: 4:ddb82e70d1a1
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: m12
changeset: 3:e62f78d544b4
parent: 1:3d5bf5654eda
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b1
changeset: 1:3d5bf5654eda
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: r1
changeset: 0:67e992f2c4f3
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: base
log -P 2
$ hg log -P 2
changeset: 6:2404bbcab562
tag: tip
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b1.1
changeset: 5:302e9dd6890d
parent: 3:e62f78d544b4
parent: 4:ddb82e70d1a1
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: m12
changeset: 4:ddb82e70d1a1
parent: 0:67e992f2c4f3
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b2
changeset: 3:e62f78d544b4
parent: 1:3d5bf5654eda
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b1
log -r tip -p --git
$ hg log -r tip -p --git
changeset: 6:2404bbcab562
tag: tip
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b1.1
diff --git a/b1 b/b1
--- a/b1
+++ b/b1
@@ -1,1 +1,2 @@
b1
+postm
log -r ""
$ hg log -r ''
hg: parse error: empty query
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-log
2010-08-15 18:34:46 +04:00
log -r <some unknown node id>
$ hg log -r 1000000000000000000000000000000000000000
abort: unknown revision '1000000000000000000000000000000000000000'!
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-log
2010-08-15 18:34:46 +04:00
log -k r1
$ hg log -k r1
changeset: 1:3d5bf5654eda
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: r1
log -p -l2 --color=always
$ hg --config extensions.color= --config color.mode=ansi \
> log -p -l2 --color=always
tests: use (esc) for all non-ASCII test output
2010-11-08 03:41:41 +03:00
\x1b[0;33mchangeset: 6:2404bbcab562\x1b[0m (esc)
tests: unify test-log
2010-08-15 18:34:46 +04:00
tag: tip
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b1.1
tests: use (esc) for all non-ASCII test output
2010-11-08 03:41:41 +03:00
\x1b[0;1mdiff -r 302e9dd6890d -r 2404bbcab562 b1\x1b[0m (esc)
\x1b[0;31;1m--- a/b1 Thu Jan 01 00:00:01 1970 +0000\x1b[0m (esc)
\x1b[0;32;1m+++ b/b1 Thu Jan 01 00:00:01 1970 +0000\x1b[0m (esc)
\x1b[0;35m@@ -1,1 +1,2 @@\x1b[0m (esc)
tests: unify test-log
2010-08-15 18:34:46 +04:00
b1
color: change diff related colors to bright versions Summary: As suggested by wez, "dim" is less supported than the bright colors. So let's use the bright versions instead. Basically, replacing "red", "red dim" with "brightred" and "red". Reviewed By: singhsrb Differential Revision: D7387254 fbshipit-source-id: f741d9e1c12115acdd1a3a2cae1658d8fae534bf
2018-03-24 12:15:55 +03:00
\x1b[0;92m+postm\x1b[0m (esc)
tests: unify test-log
2010-08-15 18:34:46 +04:00
tests: use (esc) for all non-ASCII test output
2010-11-08 03:41:41 +03:00
\x1b[0;33mchangeset: 5:302e9dd6890d\x1b[0m (esc)
tests: unify test-log
2010-08-15 18:34:46 +04:00
parent: 3:e62f78d544b4
parent: 4:ddb82e70d1a1
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: m12
tests: use (esc) for all non-ASCII test output
2010-11-08 03:41:41 +03:00
\x1b[0;1mdiff -r e62f78d544b4 -r 302e9dd6890d b2\x1b[0m (esc)
\x1b[0;31;1m--- /dev/null Thu Jan 01 00:00:00 1970 +0000\x1b[0m (esc)
\x1b[0;32;1m+++ b/b2 Thu Jan 01 00:00:01 1970 +0000\x1b[0m (esc)
\x1b[0;35m@@ -0,0 +1,1 @@\x1b[0m (esc)
color: change diff related colors to bright versions Summary: As suggested by wez, "dim" is less supported than the bright colors. So let's use the bright versions instead. Basically, replacing "red", "red dim" with "brightred" and "red". Reviewed By: singhsrb Differential Revision: D7387254 fbshipit-source-id: f741d9e1c12115acdd1a3a2cae1658d8fae534bf
2018-03-24 12:15:55 +03:00
\x1b[0;92m+b2\x1b[0m (esc)
tests: unify test-log
2010-08-15 18:34:46 +04:00
log -r tip --stat
$ hg log -r tip --stat
changeset: 6:2404bbcab562
tag: tip
user: test
date: Thu Jan 01 00:00:01 1970 +0000
summary: b1.1
b1 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
log: copy the way of ancestor traversal to --follow matcher (issue5376) We can't use fctx.linkrev() because follow() revset tries hard to simulate the traversal of changelog DAG, not filelog DAG. This patch fixes _makefollowlogfilematcher() to walk file ancestors in the same way as revset._follow(). I'll factor out a common function in future patches.
2016-09-24 13:58:23 +03:00
$ cd ..
log --follow --patch FILE in repository where linkrev isn't trustworthy
(issue5376)
$ hg init follow-dup
$ cd follow-dup
$ cat <<EOF >> .hg/hgrc
> [ui]
> logtemplate = '=== {rev}: {desc}\n'
> [diff]
> nodates = True
> EOF
$ echo 0 >> a
$ hg ci -qAm 'a0'
$ echo 1 >> a
$ hg ci -m 'a1'
$ hg up -q 0
$ echo 1 >> a
$ touch b
$ hg ci -qAm 'a1 with b'
$ echo 3 >> a
$ hg ci -m 'a3'
fctx.rev() == 2, but fctx.linkrev() == 1
$ hg log -pf a
=== 3: a3
diff -r 4ea02ba94d66 -r e7a6331a34f0 a
--- a/a
+++ b/a
@@ -1,2 +1,3 @@
0
1
+3
=== 2: a1 with b
diff -r 49b5e81287e2 -r 4ea02ba94d66 a
--- a/a
+++ b/a
@@ -1,1 +1,2 @@
0
+1
=== 0: a0
diff -r 000000000000 -r 49b5e81287e2 a
--- /dev/null
+++ b/a
@@ -0,0 +1,1 @@
+0
fctx.introrev() == 2, but fctx.linkrev() == 1
$ hg up -q 2
$ hg log -pf a
=== 2: a1 with b
diff -r 49b5e81287e2 -r 4ea02ba94d66 a
--- a/a
+++ b/a
@@ -1,1 +1,2 @@
0
+1
=== 0: a0
diff -r 000000000000 -r 49b5e81287e2 a
--- /dev/null
+++ b/a
@@ -0,0 +1,1 @@
+0
test-log: test that fctx.ancestors() can't index parents only by linkrev This covers a possible bug that could be caused by the following change: --- a/mercurial/context.py +++ b/mercurial/context.py @@ -1047,7 +1047,7 @@ class basefilectx(object): while True: for parent in c.parents()[:cut]: - visit[(parent.linkrev(), parent.filenode())] = parent + visit[parent.linkrev()] = parent if not visit: break c = visit.pop(max(visit))
2016-09-22 09:52:09 +03:00
$ cd ..
Multiple copy sources of a file:
$ hg init follow-multi
$ cd follow-multi
$ echo 0 >> a
$ hg ci -qAm 'a'
$ hg cp a b
$ hg ci -m 'a->b'
$ echo 2 >> a
$ hg ci -m 'a'
$ echo 3 >> b
$ hg ci -m 'b'
$ echo 4 >> a
$ echo 4 >> b
$ hg ci -m 'a,b'
$ echo 5 >> a
$ hg ci -m 'a0'
$ echo 6 >> b
$ hg ci -m 'b0'
$ hg up -q 4
$ echo 7 >> b
$ hg ci -m 'b1'
$ echo 8 >> a
$ hg ci -m 'a1'
$ hg rm a
$ hg mv b a
$ hg ci -m 'b1->a1'
$ hg merge -qt :local
$ hg ci -m '(a0,b1->a1)->a'
$ hg log -GT '{rev}: {desc}\n'
@ 10: (a0,b1->a1)->a
|\
| o 9: b1->a1
| |
| o 8: a1
| |
| o 7: b1
| |
o | 6: b0
| |
o | 5: a0
|/
o 4: a,b
|
o 3: b
|
o 2: a
|
o 1: a->b
|
o 0: a
since file 'a' has multiple copy sources at the revision 4, ancestors can't
be indexed solely by fctx.linkrev().
$ hg log -T '{rev}: {desc}\n' -f a
10: (a0,b1->a1)->a
9: b1->a1
7: b1
5: a0
4: a,b
3: b
2: a
1: a->b
0: a
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ cd ..
log: fix order of revisions filtered by multiple OR options (issue5100) This is the simplest workaround for the issue of the ordering of revset, which is that the expression "x or y" takes over the ordering specified by the input set (or the left-hand-side expression.) For example, the following expression A & (x | y) will be evaluated as if (A & x) | (A & y) That's wrong because revset has ordering. I'm going to fix this problem in the revset module, but that wouldn't fit to stable. So, this patch just works around the common log cases. Since this change might have some impact on performance, it is enabled only if the expression built from log options has ' or ' operation.
2016-02-15 16:46:07 +03:00
Test that log should respect the order of -rREV even if multiple OR conditions
are specified (issue5100):
$ hg init revorder
$ cd revorder
$ hg branch -q b0
$ echo 0 >> f0
$ hg ci -qAm k0 -u u0
$ hg branch -q b1
$ echo 1 >> f1
$ hg ci -qAm k1 -u u1
$ hg branch -q b2
$ echo 2 >> f2
$ hg ci -qAm k2 -u u2
$ hg update -q b2
$ echo 3 >> f2
$ hg ci -qAm k2 -u u2
$ hg update -q b1
$ echo 4 >> f1
$ hg ci -qAm k1 -u u1
$ hg update -q b0
$ echo 5 >> f0
$ hg ci -qAm k0 -u u0
summary of revisions:
$ hg log -G -T '{rev} {branch} {author} {desc} {files}\n'
@ 5 b0 u0 k0 f0
|
| o 4 b1 u1 k1 f1
| |
| | o 3 b2 u2 k2 f2
| | |
| | o 2 b2 u2 k2 f2
| |/
| o 1 b1 u1 k1 f1
|/
o 0 b0 u0 k0 f0
log -b BRANCH in ascending order:
$ hg log -r0:tip -T '{rev} {branch}\n' -b b0 -b b1
0 b0
1 b1
4 b1
5 b0
$ hg log -r0:tip -T '{rev} {branch}\n' -b b1 -b b0
0 b0
1 b1
4 b1
5 b0
log --only-branch BRANCH in descending order:
$ hg log -rtip:0 -T '{rev} {branch}\n' --only-branch b1 --only-branch b2
4 b1
3 b2
2 b2
1 b1
$ hg log -rtip:0 -T '{rev} {branch}\n' --only-branch b2 --only-branch b1
4 b1
3 b2
2 b2
1 b1
log -u USER in ascending order, against compound set:
$ hg log -r'::head()' -T '{rev} {author}\n' -u u0 -u u2
0 u0
2 u2
3 u2
5 u0
$ hg log -r'::head()' -T '{rev} {author}\n' -u u2 -u u0
0 u0
2 u2
3 u2
5 u0
log -k TEXT in descending order, against compound set:
$ hg log -r'5 + reverse(::3)' -T '{rev} {desc}\n' -k k0 -k k1 -k k2
5 k0
3 k2
2 k2
1 k1
0 k0
$ hg log -r'5 + reverse(::3)' -T '{rev} {desc}\n' -k k2 -k k1 -k k0
5 k0
3 k2
2 k2
1 k1
0 k0
log FILE in ascending order, against dagrange:
$ hg log -r1:: -T '{rev} {files}\n' f1 f2
1 f1
2 f2
3 f2
4 f1
$ hg log -r1:: -T '{rev} {files}\n' f2 f1
1 f1
2 f2
3 f2
4 f1
$ cd ..
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
User
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg init usertest
$ cd usertest
$ echo a > a
$ hg ci -A -m "a" -u "User One <user1@example.org>"
adding a
$ echo b > b
$ hg ci -A -m "b" -u "User Two <user2@example.org>"
adding b
$ hg log -u "User One <user1@example.org>"
changeset: 0:29a4c94f1924
user: User One <user1@example.org>
date: Thu Jan 01 00:00:00 1970 +0000
summary: a
$ hg log -u "user1" -u "user2"
changeset: 1:e834b5e69c0e
tag: tip
user: User Two <user2@example.org>
date: Thu Jan 01 00:00:00 1970 +0000
summary: b
changeset: 0:29a4c94f1924
user: User One <user1@example.org>
date: Thu Jan 01 00:00:00 1970 +0000
summary: a
$ hg log -u "user3"
$ cd ..
$ hg init branches
$ cd branches
$ echo a > a
$ hg ci -A -m "commit on default"
adding a
$ hg branch test
marked working directory as branch test
branch: warn on branching
2011-12-09 00:32:44 +04:00
(branches are permanent and global, did you want a bookmark?)
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ echo b > b
$ hg ci -A -m "commit on test"
adding b
$ hg up default
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo c > c
$ hg ci -A -m "commit on default"
adding c
$ hg up test
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo c > c
$ hg ci -A -m "commit on test"
adding c
log -b default
$ hg log -b default
changeset: 2:c3a4f03cc9a7
parent: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
changeset: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
log -b test
$ hg log -b test
changeset: 3:f5d8de11c2e2
branch: test
tag: tip
parent: 1:d32277701ccb
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
changeset: 1:d32277701ccb
branch: test
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
log -b dummy
$ hg log -b dummy
abort: unknown revision 'dummy'!
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-log
2010-08-15 18:34:46 +04:00
log -b .
$ hg log -b .
changeset: 3:f5d8de11c2e2
branch: test
tag: tip
parent: 1:d32277701ccb
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
changeset: 1:d32277701ccb
branch: test
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
log -b default -b test
$ hg log -b default -b test
changeset: 3:f5d8de11c2e2
branch: test
tag: tip
parent: 1:d32277701ccb
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
changeset: 2:c3a4f03cc9a7
parent: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
changeset: 1:d32277701ccb
branch: test
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
changeset: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
log -b default -b .
$ hg log -b default -b .
changeset: 3:f5d8de11c2e2
branch: test
tag: tip
parent: 1:d32277701ccb
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
changeset: 2:c3a4f03cc9a7
parent: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
changeset: 1:d32277701ccb
branch: test
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
changeset: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
log -b . -b test
$ hg log -b . -b test
changeset: 3:f5d8de11c2e2
branch: test
tag: tip
parent: 1:d32277701ccb
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
changeset: 1:d32277701ccb
branch: test
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
log -b 2
$ hg log -b 2
changeset: 2:c3a4f03cc9a7
parent: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
changeset: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
hghave: add normal-layout feature Summary: With `buck build`, the single hg binary won't be guarnateed to have access to i18n messages because directories like `mercurial/locale` do not exist on filesystem. It could also mess up with `PYTHONPATH` somehow because the python binary wrapper sometimes ignores `PYTHONPATH`. So let's add a hghave feature for it. And gate troublesome tests with `#if normal-layout`. Reviewed By: DurhamG, phillco Differential Revision: D6879876 fbshipit-source-id: 3d63605b55c8f7096093b89be824add2ec491f81
2018-02-02 23:17:46 +03:00
#if gettext normal-layout
tests: unify test-log
2010-08-15 18:34:46 +04:00
tests: add a i18n translation test for log output Upcoming patches will change the way that log output is generated so we add a test to ensure that the words 'branches', 'bookmarks', and 'tags' are still translated.
2015-01-01 01:50:19 +03:00
Test that all log names are translated (e.g. branches, bookmarks, tags):
$ hg bookmark babar -r tip
$ HGENCODING=UTF-8 LANGUAGE=de hg log -r tip
\xc3\x84nderung: 3:f5d8de11c2e2 (esc)
Zweig: test
Lesezeichen: babar
Marke: tip
Vorg\xc3\xa4nger: 1:d32277701ccb (esc)
Nutzer: test
Datum: Thu Jan 01 00:00:00 1970 +0000
Zusammenfassung: commit on test
$ hg bookmark -d babar
#endif
tests: unify test-log
2010-08-15 18:34:46 +04:00
log -p --cwd dir (in subdir)
$ mkdir dir
$ hg log -p --cwd dir
changeset: 3:f5d8de11c2e2
branch: test
tag: tip
parent: 1:d32277701ccb
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
diff -r d32277701ccb -r f5d8de11c2e2 c
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/c Thu Jan 01 00:00:00 1970 +0000
@@ -0,0 +1,1 @@
+c
changeset: 2:c3a4f03cc9a7
parent: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
diff -r 24427303d56f -r c3a4f03cc9a7 c
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/c Thu Jan 01 00:00:00 1970 +0000
@@ -0,0 +1,1 @@
+c
changeset: 1:d32277701ccb
branch: test
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on test
diff -r 24427303d56f -r d32277701ccb b
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/b Thu Jan 01 00:00:00 1970 +0000
@@ -0,0 +1,1 @@
+b
changeset: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
diff -r 000000000000 -r 24427303d56f a
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/a Thu Jan 01 00:00:00 1970 +0000
@@ -0,0 +1,1 @@
+a
log -p -R repo
$ cd dir
$ hg log -p -R .. ../a
changeset: 0:24427303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
diff -r 000000000000 -r 24427303d56f a
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/a Thu Jan 01 00:00:00 1970 +0000
@@ -0,0 +1,1 @@
+a
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
$ cd ../..
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg init follow2
$ cd follow2
# Build the following history:
# tip - o - x - o - x - x
# \ /
# o - o - o - x
# \ /
# o
#
# Where "o" is a revision containing "foo" and
# "x" is a revision without "foo"
$ touch init
$ hg ci -A -m "init, unrelated"
adding init
$ echo 'foo' > init
$ hg ci -m "change, unrelated"
$ echo 'foo' > foo
$ hg ci -A -m "add unrelated old foo"
adding foo
$ hg rm foo
$ hg ci -m "delete foo, unrelated"
$ echo 'related' > foo
$ hg ci -A -m "add foo, related"
adding foo
$ hg up 0
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ touch branch
$ hg ci -A -m "first branch, unrelated"
adding branch
$ touch foo
$ hg ci -A -m "create foo, related"
adding foo
$ echo 'change' > foo
$ hg ci -m "change foo, related"
$ hg up 6
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo 'change foo in branch' > foo
$ hg ci -m "change foo in branch, related"
$ hg merge 7
merging foo
simplemerge: move conflict warning message to filemerge The current output for a failed merge with conflict markers looks something like: merging foo warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') merging bar warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') We're going to change the way merges are done to perform all premerges before all merges, so that the output above would look like: merging foo merging bar warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') The 'warning: conflicts during merge' line has no context, so is pretty confusing. This patch will change the future output to: merging foo merging bar warning: conflicts while merging foo! (edit, then use 'hg resolve --mark') warning: conflicts while merging bar! (edit, then use 'hg resolve --mark') The hint on how to resolve the conflicts makes this a bit unwieldy, but solving that is tricky because we already hint that people run 'hg resolve' to retry unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker based resolution.
2015-10-09 23:54:52 +03:00
warning: conflicts while merging foo! (edit, then use 'hg resolve --mark')
tests: unify test-log
2010-08-15 18:34:46 +04:00
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
merge: suggest 'hg up -C .' for discarding changes, not 'hg up -C' Without specifying the parent revision of the working copy, users will update to tip, which is most likely the other head they were trying to merge, not the revision they were at before the merge.
2010-09-13 03:05:53 +04:00
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[1]
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ echo 'merge 1' > foo
$ hg resolve -m foo
resolve: add parenthesis around "no more unresolved files" message This message may be confused with an error message. Adding parenthesis around it will make it more recognisable as an informative message.
2014-07-26 05:32:49 +04:00
(no more unresolved files)
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg ci -m "First merge, related"
$ hg merge 4
merging foo
simplemerge: move conflict warning message to filemerge The current output for a failed merge with conflict markers looks something like: merging foo warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') merging bar warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') We're going to change the way merges are done to perform all premerges before all merges, so that the output above would look like: merging foo merging bar warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') The 'warning: conflicts during merge' line has no context, so is pretty confusing. This patch will change the future output to: merging foo merging bar warning: conflicts while merging foo! (edit, then use 'hg resolve --mark') warning: conflicts while merging bar! (edit, then use 'hg resolve --mark') The hint on how to resolve the conflicts makes this a bit unwieldy, but solving that is tricky because we already hint that people run 'hg resolve' to retry unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker based resolution.
2015-10-09 23:54:52 +03:00
warning: conflicts while merging foo! (edit, then use 'hg resolve --mark')
tests: unify test-log
2010-08-15 18:34:46 +04:00
1 files updated, 0 files merged, 0 files removed, 1 files unresolved
merge: suggest 'hg up -C .' for discarding changes, not 'hg up -C' Without specifying the parent revision of the working copy, users will update to tip, which is most likely the other head they were trying to merge, not the revision they were at before the merge.
2010-09-13 03:05:53 +04:00
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[1]
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ echo 'merge 2' > foo
$ hg resolve -m foo
resolve: add parenthesis around "no more unresolved files" message This message may be confused with an error message. Adding parenthesis around it will make it more recognisable as an informative message.
2014-07-26 05:32:49 +04:00
(no more unresolved files)
tests: unify test-log
2010-08-15 18:34:46 +04:00
$ hg ci -m "Last merge, related"
log: support --graph without graphlog extension The glog command is preserved in the extension for backward compatibility.
2012-07-14 21:09:22 +04:00
$ hg log --graph
tests: unify test-log
2010-08-15 18:34:46 +04:00
@ changeset: 10:4dae8563d2c5
|\ tag: tip
| | parent: 9:7b35701b003e
| | parent: 4:88176d361b69
| | user: test
| | date: Thu Jan 01 00:00:00 1970 +0000
| | summary: Last merge, related
| |
| o changeset: 9:7b35701b003e
| |\ parent: 8:e5416ad8a855
| | | parent: 7:87fe3144dcfa
| | | user: test
| | | date: Thu Jan 01 00:00:00 1970 +0000
| | | summary: First merge, related
| | |
| | o changeset: 8:e5416ad8a855
| | | parent: 6:dc6c325fe5ee
| | | user: test
| | | date: Thu Jan 01 00:00:00 1970 +0000
| | | summary: change foo in branch, related
| | |
| o | changeset: 7:87fe3144dcfa
| |/ user: test
| | date: Thu Jan 01 00:00:00 1970 +0000
| | summary: change foo, related
| |
| o changeset: 6:dc6c325fe5ee
| | user: test
| | date: Thu Jan 01 00:00:00 1970 +0000
| | summary: create foo, related
| |
| o changeset: 5:73db34516eb9
| | parent: 0:e87515fd044a
| | user: test
| | date: Thu Jan 01 00:00:00 1970 +0000
| | summary: first branch, unrelated
| |
o | changeset: 4:88176d361b69
| | user: test
| | date: Thu Jan 01 00:00:00 1970 +0000
| | summary: add foo, related
| |
o | changeset: 3:dd78ae4afb56
| | user: test
| | date: Thu Jan 01 00:00:00 1970 +0000
| | summary: delete foo, unrelated
| |
o | changeset: 2:c4c64aedf0f7
| | user: test
| | date: Thu Jan 01 00:00:00 1970 +0000
| | summary: add unrelated old foo
| |
o | changeset: 1:e5faa7440653
|/ user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: change, unrelated
|
o changeset: 0:e87515fd044a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: init, unrelated
$ hg --traceback log -f foo
changeset: 10:4dae8563d2c5
tag: tip
parent: 9:7b35701b003e
parent: 4:88176d361b69
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: Last merge, related
changeset: 9:7b35701b003e
parent: 8:e5416ad8a855
parent: 7:87fe3144dcfa
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: First merge, related
changeset: 8:e5416ad8a855
parent: 6:dc6c325fe5ee
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: change foo in branch, related
changeset: 7:87fe3144dcfa
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: change foo, related
changeset: 6:dc6c325fe5ee
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: create foo, related
changeset: 4:88176d361b69
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: add foo, related
merge with stable
2010-09-23 03:59:02 +04:00
log: fix log -rREV FILE when REV isnt the last filerev (issue2492) Regression from 9f0026001bfd. That previous commit is not supposed to affect log calls without --follow, so we step out of this codepath if follow is not True, and it's enough to fix the regression. When --follow is given, we fix the issue by taking into account changesets that have a rev > maxrev to build the filegraph: even if those files are not included in the final result, it's still needed to walk correctly the graph from the end of the filelog to minrev, to track accurately renames.
2010-11-10 20:10:37 +03:00
Also check when maxrev < lastrevfilelog
$ hg --traceback log -f -r4 foo
changeset: 4:88176d361b69
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: add foo, related
log: make -fr show complete history from the given revs Right now it's very obtuse to show the history of a particular rev (hg log -r 'reverse(::foo)'). This changes the -f option to make it follow history for the revs specified by -r. The current -f -r behavior is to limit the result of -r to only the commits that are ancestors of the current working copy. Changing this is a bit of a BC break, but the old behavior is A) rare, B) easy to emulate (& ::.), and C) currently undefined. The new behavior is frequently requested enough that I think the change is worth it.
2015-02-06 22:04:55 +03:00
changeset: 2:c4c64aedf0f7
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: add unrelated old foo
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
$ cd ..
log: fix log -rREV FILE when REV isnt the last filerev (issue2492) Regression from 9f0026001bfd. That previous commit is not supposed to affect log calls without --follow, so we step out of this codepath if follow is not True, and it's enough to fix the regression. When --follow is given, we fix the issue by taking into account changesets that have a rev > maxrev to build the filegraph: even if those files are not included in the final result, it's still needed to walk correctly the graph from the end of the filelog to minrev, to track accurately renames.
2010-11-10 20:10:37 +03:00
tests: added a short description to issue numbers Many tests already had a short line to describe what IssueXXX is about. I find that quite useful when reading a test.
2010-09-24 12:13:49 +04:00
Issue2383: hg log showing _less_ differences than hg diff
merge with stable
2010-09-23 03:59:02 +04:00
$ hg init issue2383
$ cd issue2383
Create a test repo:
$ echo a > a
$ hg ci -Am0
adding a
$ echo b > b
$ hg ci -Am1
adding b
$ hg co 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo b > a
$ hg ci -m2
Merge:
$ hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Make sure there's a file listed in the merge to trigger the bug:
$ echo c > a
$ hg ci -m3
Two files shown here in diff:
$ hg diff --rev 2:3
diff -r b09be438c43a -r 8e07aafe1edc a
--- a/a Thu Jan 01 00:00:00 1970 +0000
+++ b/a Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +1,1 @@
-b
+c
diff -r b09be438c43a -r 8e07aafe1edc b
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/b Thu Jan 01 00:00:00 1970 +0000
@@ -0,0 +1,1 @@
+b
Diff here should be the same:
$ hg log -vpr 3
changeset: 3:8e07aafe1edc
tag: tip
parent: 2:b09be438c43a
parent: 1:925d80f479bb
user: test
date: Thu Jan 01 00:00:00 1970 +0000
files: a
description:
3
diff -r b09be438c43a -r 8e07aafe1edc a
--- a/a Thu Jan 01 00:00:00 1970 +0000
+++ b/a Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +1,1 @@
-b
+c
diff -r b09be438c43a -r 8e07aafe1edc b
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/b Thu Jan 01 00:00:00 1970 +0000
@@ -0,0 +1,1 @@
+b
$ cd ..
log: fix log -rREV FILE when REV isnt the last filerev (issue2492) Regression from 9f0026001bfd. That previous commit is not supposed to affect log calls without --follow, so we step out of this codepath if follow is not True, and it's enough to fix the regression. When --follow is given, we fix the issue by taking into account changesets that have a rev > maxrev to build the filegraph: even if those files are not included in the final result, it's still needed to walk correctly the graph from the end of the filelog to minrev, to track accurately renames.
2010-11-10 20:10:37 +03:00
'hg log -r rev fn' when last(filelog(fn)) != rev
tests: cleanup of tests that got lost in their own nested directories Some tests ended up in a directory several directories deeper than $TESTTMP, usually because some 'cd ..' had been forgotten between different test cases. Add 'cd ..' where they are missing so the tests get back where they started.
2012-06-11 03:38:32 +04:00
$ hg init simplelog
$ cd simplelog
log: fix log -rREV FILE when REV isnt the last filerev (issue2492) Regression from 9f0026001bfd. That previous commit is not supposed to affect log calls without --follow, so we step out of this codepath if follow is not True, and it's enough to fix the regression. When --follow is given, we fix the issue by taking into account changesets that have a rev > maxrev to build the filegraph: even if those files are not included in the final result, it's still needed to walk correctly the graph from the end of the filelog to minrev, to track accurately renames.
2010-11-10 20:10:37 +03:00
$ echo f > a
$ hg ci -Am'a' -d '0 0'
adding a
$ echo f >> a
$ hg ci -Am'a bis' -d '1 0'
$ hg log -r0 a
changeset: 0:9f758d63dcde
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: a
test: use obsolescence marker to test hidden Instead of using a custom dedicated extension.
2012-12-04 18:25:22 +04:00
enable obsolete to test hidden feature
obsolete: update tests to use obsolete options The obsolete._enabled flag has become a config option. This updates all but one of the tests to use the minimal number of flags necessary for them to pass. For most tests this is just 'createmarkers', for a couple tests it's 'allowunstable', and for even fewer it's 'exchange'.
2014-10-15 00:34:25 +04:00
$ cat >> $HGRCPATH << EOF
> [experimental]
config: use 'experimental.evolution.create-markers' Extract 'experimental.evolution' = createmarkers as 'experimental.evolution.createmarkers'. We keep the new option in the 'experimental.evolution' namespace in order to stay coherent with other options ('experimental.evolution.bundle-obsmarker' and 'experimental.evolution.track-operation') ease the renaming as possibly 'evolution.createmarkers'. Differential Revision: https://phab.mercurial-scm.org/D1149
2017-09-28 20:19:06 +03:00
> evolution.createmarkers=True
log: do not display hidden changeset We add a --hidden option to display them.
2011-06-16 03:58:00 +04:00
> EOF
test: use obsolescence marker to test hidden Instead of using a custom dedicated extension.
2012-12-04 18:25:22 +04:00
log: do not display hidden changeset We add a --hidden option to display them.
2011-06-16 03:58:00 +04:00
$ hg log --template='{rev}:{node}\n'
1:a765632148dc55d38c35c4f247c618701886cb2f
0:9f758d63dcde62d547ebfb08e1e7ee96535f2b05
test: use obsolescence marker to test hidden Instead of using a custom dedicated extension.
2012-12-04 18:25:22 +04:00
$ hg debugobsolete a765632148dc55d38c35c4f247c618701886cb2f
debugobsolete: also report the number of obsoleted changesets This seems useful to have the number of obsoleted changesets when calling debugobsolete.
2017-07-16 03:33:14 +03:00
obsoleted 1 changesets
test: use obsolescence marker to test hidden Instead of using a custom dedicated extension.
2012-12-04 18:25:22 +04:00
$ hg up null -q
log: do not display hidden changeset We add a --hidden option to display them.
2011-06-16 03:58:00 +04:00
$ hg log --template='{rev}:{node}\n'
0:9f758d63dcde62d547ebfb08e1e7ee96535f2b05
$ hg log --template='{rev}:{node}\n' --hidden
1:a765632148dc55d38c35c4f247c618701886cb2f
0:9f758d63dcde62d547ebfb08e1e7ee96535f2b05
revlog: handle hidden revs in _partialmatch (issue3979) Looking up hidden prefixes could cause a no node exception Looking up unique non-hidden prefixes could be ambiguous
2013-07-24 02:28:12 +04:00
$ hg log -r a
repoview: issue a special message when filtering hidden changesets Hidden changesets are by far the most common error case and is the only one[1] that can reach the user. We move to a friendlier message with a hint about how to access the data anyway. We should probably point to a help topic instead but we do not have such a topic yet. Example of the new output abort: hidden revision '4'! (use --hidden to access hidden revisions) [1] Actually, filtering from "served" can also reach the user during certain exchange operations.
2014-10-18 02:25:32 +04:00
abort: hidden revision 'a'!
(use --hidden to access hidden revisions)
revlog: handle hidden revs in _partialmatch (issue3979) Looking up hidden prefixes could cause a no node exception Looking up unique non-hidden prefixes could be ambiguous
2013-07-24 02:28:12 +04:00
[255]
i18n: use "encoding.lower()" to normalize specified keywords for log searching some problematic encoding (e.g.: cp932) uses ASCII alphabet characters in byte sequence of multi byte characters. "str.lower()" on such byte sequence may treat distinct characters as same one, and cause unexpected log matching. this patch uses "encoding.lower()" instead of "str.lower()" to normalize strings for compare.
2011-12-25 15:35:16 +04:00
hidden: use both parents of working directory If we are merging with and extinct revision, this extinct revision should not be hidden.
2013-01-08 20:31:00 +04:00
test that parent prevent a changeset to be hidden
clfilter: enforce hidden changeset globally The dispatch code now enables filtering of "hidden" changesets globally. The filter is installed before command and extension invocation. The `--hidden` switch is now global and disables this filtering for any command. Code in log dedicated to changeset exclusion is removed as this global filtering has the same effect.
2013-01-08 23:37:37 +04:00
$ hg up 1 -q --hidden
hidden: use both parents of working directory If we are merging with and extinct revision, this extinct revision should not be hidden.
2013-01-08 20:31:00 +04:00
$ hg log --template='{rev}:{node}\n'
1:a765632148dc55d38c35c4f247c618701886cb2f
0:9f758d63dcde62d547ebfb08e1e7ee96535f2b05
test that second parent prevent a changeset to be hidden too
$ hg debugsetparents 0 1 # nothing suitable to merge here
$ hg log --template='{rev}:{node}\n'
1:a765632148dc55d38c35c4f247c618701886cb2f
0:9f758d63dcde62d547ebfb08e1e7ee96535f2b05
filtering: test that bookmarks prevent hiding of changesets
2013-01-29 06:25:56 +04:00
$ hg debugsetparents 1
$ hg up -q null
bookmarks prevent a changeset being hidden
$ hg bookmark --hidden -r 1 X
$ hg log --template '{rev}:{node}\n'
1:a765632148dc55d38c35c4f247c618701886cb2f
0:9f758d63dcde62d547ebfb08e1e7ee96535f2b05
bookmarks: don't use bookmarks.listbookmarks in local computations bookmarks.listbookmarks is for wire-protocol use. The normal way to get all the bookmarks on a local repository is repo._bookmarks.
2013-01-28 00:24:37 +04:00
$ hg bookmark -d X
divergent bookmarks are not hidden
$ hg bookmark --hidden -r 1 X@foo
$ hg log --template '{rev}:{node}\n'
1:a765632148dc55d38c35c4f247c618701886cb2f
0:9f758d63dcde62d547ebfb08e1e7ee96535f2b05
hidden: use both parents of working directory If we are merging with and extinct revision, this extinct revision should not be hidden.
2013-01-08 20:31:00 +04:00
revset: do not rewrite ':y' to '0:y' (issue5385) That's no longer valid since the revision 0 may be hidden. Bypass validating the existence of '0' and filter it by spanset.
2016-10-01 14:20:11 +03:00
test hidden revision 0 (issue5385)
$ hg bookmark -d X@foo
$ hg up null -q
$ hg debugobsolete 9f758d63dcde62d547ebfb08e1e7ee96535f2b05
debugobsolete: also report the number of obsoleted changesets This seems useful to have the number of obsoleted changesets when calling debugobsolete.
2017-07-16 03:33:14 +03:00
obsoleted 1 changesets
revset: do not rewrite ':y' to '0:y' (issue5385) That's no longer valid since the revision 0 may be hidden. Bypass validating the existence of '0' and filter it by spanset.
2016-10-01 14:20:11 +03:00
$ echo f > b
$ hg ci -Am'b' -d '2 0'
adding b
$ echo f >> b
$ hg ci -m'b bis' -d '3 0'
$ hg log -T'{rev}:{node}\n'
3:d7d28b288a6b83d5d2cf49f10c5974deed3a1d2e
2:94375ec45bddd2a824535fc04855bd058c926ec0
$ hg log -T'{rev}:{node}\n' -r:
2:94375ec45bddd2a824535fc04855bd058c926ec0
3:d7d28b288a6b83d5d2cf49f10c5974deed3a1d2e
$ hg log -T'{rev}:{node}\n' -r:tip
2:94375ec45bddd2a824535fc04855bd058c926ec0
3:d7d28b288a6b83d5d2cf49f10c5974deed3a1d2e
$ hg log -T'{rev}:{node}\n' -r:0
abort: hidden revision '0'!
(use --hidden to access hidden revisions)
[255]
$ hg log -T'{rev}:{node}\n' -f
3:d7d28b288a6b83d5d2cf49f10c5974deed3a1d2e
2:94375ec45bddd2a824535fc04855bd058c926ec0
i18n: use "encoding.lower()" to normalize specified keywords for log searching some problematic encoding (e.g.: cp932) uses ASCII alphabet characters in byte sequence of multi byte characters. "str.lower()" on such byte sequence may treat distinct characters as same one, and cause unexpected log matching. this patch uses "encoding.lower()" instead of "str.lower()" to normalize strings for compare.
2011-12-25 15:35:16 +04:00
clear extensions configuration
$ echo '[extensions]' >> $HGRCPATH
test: use obsolescence marker to test hidden Instead of using a custom dedicated extension.
2012-12-04 18:25:22 +04:00
$ echo "obs=!" >> $HGRCPATH
i18n: use "encoding.lower()" to normalize specified keywords for log searching some problematic encoding (e.g.: cp932) uses ASCII alphabet characters in byte sequence of multi byte characters. "str.lower()" on such byte sequence may treat distinct characters as same one, and cause unexpected log matching. this patch uses "encoding.lower()" instead of "str.lower()" to normalize strings for compare.
2011-12-25 15:35:16 +04:00
$ cd ..
test -u/-k for problematic encoding
# unicode: cp932:
# u30A2 0x83 0x41(= 'A')
# u30C2 0x83 0x61(= 'a')
$ hg init problematicencoding
$ cd problematicencoding
tests: replace yet more calls to `python` with $PYTHON These are some simple cases. More to come in a future change. Reviewers: krbullock Reviewed By: krbullock Differential Revision: https://phab.mercurial-scm.org/D4
2017-07-05 19:10:11 +03:00
$ $PYTHON > setup.sh <<EOF
tests: clean up many print statements to be print functions instead Differential Revision: https://phab.mercurial-scm.org/D294
2017-06-15 21:22:25 +03:00
> print(u'''
i18n: use "encoding.lower()" to normalize specified keywords for log searching some problematic encoding (e.g.: cp932) uses ASCII alphabet characters in byte sequence of multi byte characters. "str.lower()" on such byte sequence may treat distinct characters as same one, and cause unexpected log matching. this patch uses "encoding.lower()" instead of "str.lower()" to normalize strings for compare.
2011-12-25 15:35:16 +04:00
> echo a > text
> hg add text
> hg --encoding utf-8 commit -u '\u30A2' -m none
> echo b > text
> hg --encoding utf-8 commit -u '\u30C2' -m none
> echo c > text
> hg --encoding utf-8 commit -u none -m '\u30A2'
> echo d > text
> hg --encoding utf-8 commit -u none -m '\u30C2'
tests: clean up many print statements to be print functions instead Differential Revision: https://phab.mercurial-scm.org/D294
2017-06-15 21:22:25 +03:00
> '''.encode('utf-8'))
i18n: use "encoding.lower()" to normalize specified keywords for log searching some problematic encoding (e.g.: cp932) uses ASCII alphabet characters in byte sequence of multi byte characters. "str.lower()" on such byte sequence may treat distinct characters as same one, and cause unexpected log matching. this patch uses "encoding.lower()" instead of "str.lower()" to normalize strings for compare.
2011-12-25 15:35:16 +04:00
> EOF
$ sh < setup.sh
test in problematic encoding
tests: replace yet more calls to `python` with $PYTHON These are some simple cases. More to come in a future change. Reviewers: krbullock Reviewed By: krbullock Differential Revision: https://phab.mercurial-scm.org/D4
2017-07-05 19:10:11 +03:00
$ $PYTHON > test.sh <<EOF
tests: clean up many print statements to be print functions instead Differential Revision: https://phab.mercurial-scm.org/D294
2017-06-15 21:22:25 +03:00
> print(u'''
i18n: use "encoding.lower()" to normalize specified keywords for log searching some problematic encoding (e.g.: cp932) uses ASCII alphabet characters in byte sequence of multi byte characters. "str.lower()" on such byte sequence may treat distinct characters as same one, and cause unexpected log matching. this patch uses "encoding.lower()" instead of "str.lower()" to normalize strings for compare.
2011-12-25 15:35:16 +04:00
> hg --encoding cp932 log --template '{rev}\\n' -u '\u30A2'
> echo ====
> hg --encoding cp932 log --template '{rev}\\n' -u '\u30C2'
> echo ====
> hg --encoding cp932 log --template '{rev}\\n' -k '\u30A2'
> echo ====
> hg --encoding cp932 log --template '{rev}\\n' -k '\u30C2'
tests: clean up many print statements to be print functions instead Differential Revision: https://phab.mercurial-scm.org/D294
2017-06-15 21:22:25 +03:00
> '''.encode('cp932'))
i18n: use "encoding.lower()" to normalize specified keywords for log searching some problematic encoding (e.g.: cp932) uses ASCII alphabet characters in byte sequence of multi byte characters. "str.lower()" on such byte sequence may treat distinct characters as same one, and cause unexpected log matching. this patch uses "encoding.lower()" instead of "str.lower()" to normalize strings for compare.
2011-12-25 15:35:16 +04:00
> EOF
$ sh < test.sh
0
====
1
====
2
0
====
3
1
$ cd ..
log: speed up hg log for untracked files (issue1340) 'hg log' on untracked files tends to be fairly slow. The root cause is that we end up using the 'slowpath' when we can't find a revlog for the files listed. This could happen if the file in question is an untracked file, or it is a directory. This diff tries to speed up 'hg log' (by avoiding the slowpath) for files if we can determine if that file is not (and was never) a directory. We use the previously added store.__contains__ methods to test if the directory exists (or existed) in the store. To avoid changing any existing semantics, this 'optimization' kicks in only when none of the files listed as arguments to the hg log command exist in the store.
2012-09-14 10:50:45 +04:00
test hg log on non-existent files and on directories
$ hg init issue1340
$ cd issue1340
$ mkdir d1; mkdir D2; mkdir D3.i; mkdir d4.hg; mkdir d5.d; mkdir .d6
$ echo 1 > d1/f1
$ echo 1 > D2/f1
$ echo 1 > D3.i/f1
$ echo 1 > d4.hg/f1
$ echo 1 > d5.d/f1
$ echo 1 > .d6/f1
test-log: fix / vs \ issues on Windows introduced with 9827ad56acbc test-log.t fails on Windows with --- c:\Users\buildbot\w2k8\Windows_2008_R2_hg_tests\build\tests\test-log.t +++ c:\Users\buildbot\w2k8\Windows_2008_R2_hg_tests\build\tests\test-log.t.err @@ -1225,12 +1225,12 @@ $ echo 1 > d5.d/f1 $ echo 1 > .d6/f1 $ hg add . - adding .d6/f1 - adding D2/f1 - adding D3.i/f1 - adding d1/f1 - adding d4.hg/f1 - adding d5.d/f1 + adding .d6\f1 + adding D2\f1 + adding D3.i\f1 + adding d1\f1 + adding d4.hg\f1 + adding d5.d\f1 $ hg commit -m "a bunch of weird directories" $ hg log -l1 d1/f1 | grep changeset changeset: 0:65624cd9070a
2012-10-12 12:12:26 +04:00
$ hg -q add .
log: speed up hg log for untracked files (issue1340) 'hg log' on untracked files tends to be fairly slow. The root cause is that we end up using the 'slowpath' when we can't find a revlog for the files listed. This could happen if the file in question is an untracked file, or it is a directory. This diff tries to speed up 'hg log' (by avoiding the slowpath) for files if we can determine if that file is not (and was never) a directory. We use the previously added store.__contains__ methods to test if the directory exists (or existed) in the store. To avoid changing any existing semantics, this 'optimization' kicks in only when none of the files listed as arguments to the hg log command exist in the store.
2012-09-14 10:50:45 +04:00
$ hg commit -m "a bunch of weird directories"
$ hg log -l1 d1/f1 | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 f1
$ hg log -l1 . | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 ./ | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 d1 | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 D2 | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 D2/f1 | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 D3.i | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 D3.i/f1 | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 d4.hg | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 d4.hg/f1 | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 d5.d | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 d5.d/f1 | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 .d6 | grep changeset
changeset: 0:65624cd9070a
$ hg log -l1 .d6/f1 | grep changeset
changeset: 0:65624cd9070a
log: remove any ancestors of nullrev (issue3772) For the special case, ":null" we remove the implied revision 0 since that wouldn't make any sense here. A test case is added to make sure only nullrev is shown.
2013-01-23 10:12:52 +04:00
issue3772: hg log -r :null showing revision 0 as well
$ hg log -r :null
hg log: solves bug regarding hg log -r 0:null (issue4039) 'hg log -r 0:null' was showing only one changeset(the '-1' one) instead of the first two changesets.
2014-03-12 12:26:48 +04:00
changeset: 0:65624cd9070a
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: a bunch of weird directories
log: remove any ancestors of nullrev (issue3772) For the special case, ":null" we remove the implied revision 0 since that wouldn't make any sense here. A test case is added to make sure only nullrev is shown.
2013-01-23 10:12:52 +04:00
changeset: -1:000000000000
user:
date: Thu Jan 01 00:00:00 1970 +0000
tests: add regression tests for another revrange edge case These tests would've passed before 99686e12b04e and a8620592704a. Inserting them to make sure that continues to be the case.
2013-01-23 21:55:39 +04:00
$ hg log -r null:null
changeset: -1:000000000000
user:
date: Thu Jan 01 00:00:00 1970 +0000
changeset_printer: display p1rev:p1node with "+" suffix for workingctx Still templater can't handle workingctx, which will be fixed later.
2015-03-14 14:01:30 +03:00
working-directory revision requires special treatment
tests: include modified/added/removed files in "log -r wdir()" output This patch prepares for the test of "hg log -r wdir() -p".
2016-03-13 17:21:45 +03:00
clean:
$ hg log -r 'wdir()' --debug
changeset: 2147483647:ffffffffffffffffffffffffffffffffffffffff
phase: draft
parent: 0:65624cd9070a035fa7191a54f2b8af39f16b0c08
parent: -1:0000000000000000000000000000000000000000
user: test
date: [A-Za-z0-9:+ ]+ (re)
extra: branch=default
tests: add test for "log -r wdir() -p" (issue4871) The issue has been fixed by 0f01b8ad724c, "cmdutil.changeset_printer: pass context into showpatch()". This patch adds test to prevent future regression.
2016-03-13 17:27:27 +03:00
$ hg log -r 'wdir()' -p --stat
changeset: 2147483647:ffffffffffff
parent: 0:65624cd9070a
user: test
date: [A-Za-z0-9:+ ]+ (re)
tests: include modified/added/removed files in "log -r wdir()" output This patch prepares for the test of "hg log -r wdir() -p".
2016-03-13 17:21:45 +03:00
dirty:
$ echo 2 >> d1/f1
$ echo 2 > d1/f2
$ hg add d1/f2
$ hg remove .d6/f1
$ hg status
M d1/f1
A d1/f2
R .d6/f1
changeset_printer: display p1rev:p1node with "+" suffix for workingctx Still templater can't handle workingctx, which will be fixed later.
2015-03-14 14:01:30 +03:00
$ hg log -r 'wdir()'
changeset_printer: display wdirrev/wdirnode values for workingctx Because we want to eliminate "if"s in the default template, it makes sense to display wdirrev/wdirnode values for now. wdir() is still experimental, so the output of "log -r'wdir()'" may change in future.
2015-07-04 11:19:49 +03:00
changeset: 2147483647:ffffffffffff
changeset_printer: use node.wdirrev to calculate meaningful parentrevs Because we defined the working-directory revision is INT_MAX, it makes sense that "hg log -r 'wdir()'" displays the "parent:" field. This is the same for two revisions that are semantically contiguous but the intermediate revisions are hidden.
2015-07-02 16:03:06 +03:00
parent: 0:65624cd9070a
changeset_printer: display p1rev:p1node with "+" suffix for workingctx Still templater can't handle workingctx, which will be fixed later.
2015-03-14 14:01:30 +03:00
user: test
date: [A-Za-z0-9:+ ]+ (re)
$ hg log -r 'wdir()' -q
changeset_printer: display wdirrev/wdirnode values for workingctx Because we want to eliminate "if"s in the default template, it makes sense to display wdirrev/wdirnode values for now. wdir() is still experimental, so the output of "log -r'wdir()'" may change in future.
2015-07-04 11:19:49 +03:00
2147483647:ffffffffffff
changeset_printer: display p1rev:p1node with "+" suffix for workingctx Still templater can't handle workingctx, which will be fixed later.
2015-03-14 14:01:30 +03:00
changeset_printer: hide manifest node for workingctx Because workingctx has no manifest, it makes sense to hide "manifest:" row completely.
2015-03-14 11:33:22 +03:00
$ hg log -r 'wdir()' --debug
changeset_printer: display wdirrev/wdirnode values for workingctx Because we want to eliminate "if"s in the default template, it makes sense to display wdirrev/wdirnode values for now. wdir() is still experimental, so the output of "log -r'wdir()'" may change in future.
2015-07-04 11:19:49 +03:00
changeset: 2147483647:ffffffffffffffffffffffffffffffffffffffff
changeset_printer: hide manifest node for workingctx Because workingctx has no manifest, it makes sense to hide "manifest:" row completely.
2015-03-14 11:33:22 +03:00
phase: draft
parent: 0:65624cd9070a035fa7191a54f2b8af39f16b0c08
parent: -1:0000000000000000000000000000000000000000
user: test
date: [A-Za-z0-9:+ ]+ (re)
tests: include modified/added/removed files in "log -r wdir()" output This patch prepares for the test of "hg log -r wdir() -p".
2016-03-13 17:21:45 +03:00
files: d1/f1
files+: d1/f2
files-: .d6/f1
changeset_printer: hide manifest node for workingctx Because workingctx has no manifest, it makes sense to hide "manifest:" row completely.
2015-03-14 11:33:22 +03:00
extra: branch=default
tests: add test for "log -r wdir() -p" (issue4871) The issue has been fixed by 0f01b8ad724c, "cmdutil.changeset_printer: pass context into showpatch()". This patch adds test to prevent future regression.
2016-03-13 17:27:27 +03:00
$ hg log -r 'wdir()' -p --stat --git
changeset: 2147483647:ffffffffffff
parent: 0:65624cd9070a
user: test
date: [A-Za-z0-9:+ ]+ (re)
.d6/f1 | 1 -
d1/f1 | 1 +
d1/f2 | 1 +
3 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/.d6/f1 b/.d6/f1
deleted file mode 100644
--- a/.d6/f1
+++ /dev/null
@@ -1,1 +0,0 @@
-1
diff --git a/d1/f1 b/d1/f1
--- a/d1/f1
+++ b/d1/f1
@@ -1,1 +1,2 @@
1
+2
diff --git a/d1/f2 b/d1/f2
new file mode 100644
--- /dev/null
+++ b/d1/f2
@@ -0,0 +1,1 @@
+2
jsonchangeset: set rev and node to "null" for workingctx
2015-03-14 14:15:40 +03:00
$ hg log -r 'wdir()' -Tjson
[
{
"rev": null,
"node": null,
"branch": "default",
"phase": "draft",
"user": "test",
"date": [*, 0], (glob)
"desc": "",
"bookmarks": [],
workingctx: don't report the tags for its parents This fixes the bad distance calculation for '{latesttagdistance}' mentioned in the previous patch.
2015-06-28 20:38:03 +03:00
"tags": [],
jsonchangeset: set rev and node to "null" for workingctx
2015-03-14 14:15:40 +03:00
"parents": ["65624cd9070a035fa7191a54f2b8af39f16b0c08"]
}
]
$ hg log -r 'wdir()' -Tjson -q
[
{
"rev": null,
"node": null
}
]
jsonchangeset: set manifest node to "null" for workingctx Unlike changeset_printer, it does not hide the manifest field because JSON output will be parsed by machine where explicit "null" will be more useful than nothing.
2015-03-14 14:16:35 +03:00
$ hg log -r 'wdir()' -Tjson --debug
[
{
"rev": null,
"node": null,
"branch": "default",
"phase": "draft",
"user": "test",
"date": [*, 0], (glob)
"desc": "",
"bookmarks": [],
workingctx: don't report the tags for its parents This fixes the bad distance calculation for '{latesttagdistance}' mentioned in the previous patch.
2015-06-28 20:38:03 +03:00
"tags": [],
jsonchangeset: set manifest node to "null" for workingctx Unlike changeset_printer, it does not hide the manifest field because JSON output will be parsed by machine where explicit "null" will be more useful than nothing.
2015-03-14 14:16:35 +03:00
"parents": ["65624cd9070a035fa7191a54f2b8af39f16b0c08"],
"manifest": null,
"extra": {"branch": "default"},
tests: include modified/added/removed files in "log -r wdir()" output This patch prepares for the test of "hg log -r wdir() -p".
2016-03-13 17:21:45 +03:00
"modified": ["d1/f1"],
"added": ["d1/f2"],
"removed": [".d6/f1"]
jsonchangeset: set manifest node to "null" for workingctx Unlike changeset_printer, it does not hide the manifest field because JSON output will be parsed by machine where explicit "null" will be more useful than nothing.
2015-03-14 14:16:35 +03:00
}
]
tests: include modified/added/removed files in "log -r wdir()" output This patch prepares for the test of "hg log -r wdir() -p".
2016-03-13 17:21:45 +03:00
$ hg revert -aqC
namespaces: add test for log Now that we have enough features in the namespaces api, we add a test for it.
2014-10-22 06:49:23 +04:00
Check that adding an arbitrary name shows up in log automatically
$ cat > ../names.py <<EOF
> """A small extension to test adding arbitrary names to a repo"""
tests: update test-log to pass our import checker
2017-08-22 23:58:22 +03:00
> from __future__ import absolute_import
> from mercurial import namespaces
namespaces: add test for log Now that we have enough features in the namespaces api, we add a test for it.
2014-10-22 06:49:23 +04:00
>
> def reposetup(ui, repo):
> foo = {'foo': repo[0].node()}
namespaces: use named args for namespace api This is just a style change but makes adding new arguments more robust for callers.
2015-01-15 06:55:20 +03:00
> names = lambda r: foo.keys()
> namemap = lambda r, name: foo.get(name)
> nodemap = lambda r, node: [name for name, n in foo.iteritems()
> if n == node]
tests: update test-log to pass our import checker
2017-08-22 23:58:22 +03:00
> ns = namespaces.namespace(
> "bars", templatename="bar", logname="barlog",
> colorname="barcolor", listnames=names, namemap=namemap,
> nodemap=nodemap)
namespaces: use named args for namespace api This is just a style change but makes adding new arguments more robust for callers.
2015-01-15 06:55:20 +03:00
>
namespaces: add test for log Now that we have enough features in the namespaces api, we add a test for it.
2014-10-22 06:49:23 +04:00
> repo.names.addnamespace(ns)
> EOF
log: remove any ancestors of nullrev (issue3772) For the special case, ":null" we remove the implied revision 0 since that wouldn't make any sense here. A test case is added to make sure only nullrev is shown.
2013-01-23 10:12:52 +04:00
namespaces: add test for log Now that we have enough features in the namespaces api, we add a test for it.
2014-10-22 06:49:23 +04:00
$ hg --config extensions.names=../names.py log -r 0
changeset: 0:65624cd9070a
tag: tip
log: use namespace logname and colorname Now that we have the machinary to change the log name and the color label used, let's use that. Tests have been updated accordingly.
2015-01-15 07:29:47 +03:00
barlog: foo
namespaces: add test for log Now that we have enough features in the namespaces api, we add a test for it.
2014-10-22 06:49:23 +04:00
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: a bunch of weird directories
log: use namespace logname and colorname Now that we have the machinary to change the log name and the color label used, let's use that. Tests have been updated accordingly.
2015-01-15 07:29:47 +03:00
$ hg --config extensions.names=../names.py \
> --config extensions.color= --config color.log.barcolor=red \
> --color=always log -r 0
\x1b[0;33mchangeset: 0:65624cd9070a\x1b[0m (esc)
tag: tip
\x1b[0;31mbarlog: foo\x1b[0m (esc)
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: a bunch of weird directories
$ hg --config extensions.names=../names.py log -r 0 --template '{bars}\n'
foo
templater: provide hint for templates with parse errors Summary: Help people debug issues by providing useful hints when templates fail to parse. Differential Revision: D7148780 fbshipit-source-id: bd2b0f2bdeb0c970732fcaf53854d4a003b08571
2018-03-16 21:14:41 +03:00
Templater parse errors:
simple error
$ hg log -r . -T '{shortest(node}'
hg: parse error at 15: unexpected token: end
({shortest(node}
^ here)
[255]
multi-line template with error
$ hg log -r . -T 'line 1
> line2
> {shortest(node}
> line4\nline5'
hg: parse error at 28: unexpected token: end
(line 1\nline2\n{shortest(node}\nline4\nline5
^ here)
[255]
log: fix log -f slow path to actually follow history The revset created when -f was used with a slow path (for patterns and directories) did not actually contain any logic to enforce follow. Instead it was depending on the passed in subset to already be limited (which was limited to :. but not ::.). This fixes it by adding a '& ::.' to any -f log revset. hg log -f <file> is still broken, in that it can return results that aren't actually ancestors of the current file, but fixing that has major perf implications, so we'll deal with it later.
2014-12-06 01:27:32 +03:00
$ cd ..
hg log -f dir across branches
$ hg init acrossbranches
$ cd acrossbranches
$ mkdir d
$ echo a > d/a && hg ci -Aqm a
$ echo b > d/a && hg ci -Aqm b
$ hg up -q 0
$ echo b > d/a && hg ci -Aqm c
$ hg log -f d -T '{desc}' -G
@ c
|
o a
largefiles: remove the extension Summary: `lfs` is the better large file solution. `largefiles` is rarely used, and its implementation is less clean. So let's remove it. Test Plan: Ran all tests. A subrepo test was removed instead of cleaned up since the longer term plan is to also drop subrepo support. Reviewers: phillco, #mercurial Reviewed By: phillco Differential Revision: https://phabricator.intern.facebook.com/D6740361 Signature: 6740361:1516225594:555e3803571ad05e0434021897a2823ac99347ae
2018-01-17 22:50:44 +03:00
$ hg log -f d -T '{desc}' -G
largefiles: don't interfere with logging normal files The previous code was adding standin files to the matcher's file list when neither the standin file nor the original existed in the context. Somehow, this was confusing the logging code into behaving differently from when the extension wasn't loaded. It seems that this was an attempt to support naming a directory that only contains largefiles, as a test fails if the else clause is dropped entirely. Therefore, only append the "standin" if it is a directory. This was found by running the test suite with --config extensions.largefiles=. The first added test used to log an additional cset that wasn't logged normally. The only relation it had to file 'a' is that 'a' was the source of a move, but it isn't clear why having '.hglf/a' in the list causes this change: @@ -47,6 +47,11 @@ Make sure largefiles doesn't interfere with logging a regular file $ hg log a --config extensions.largefiles= + changeset: 3:2ca5ba701980 + user: test + date: Thu Jan 01 00:00:04 1970 +0000 + summary: d + changeset: 0:9161b9aeaf16 user: test date: Thu Jan 01 00:00:01 1970 +0000 The second added test used to complain about a file not being in the parent revision: @@ -1638,10 +1643,8 @@ Ensure that largefiles doesn't intefere with following a normal file $ hg --config extensions.largefiles= log -f d -T '{desc}' -G - @ c - | - o a - + abort: cannot follow file not in parent revision: ".hglf/d" + [255] $ hg log -f d/a -T '{desc}' -G @ c | Note that there is still something fishy with the largefiles code, because when using a glob pattern like this: $ hg log 'glob:sub/*' the pattern list would contain '.hglf/glob:sub/*'. None of the tests show this (this test lives in test-largefiles.t at 1349), it was just something that I noticed when the code was loaded up with print statements.
2015-01-31 04:44:11 +03:00
@ c
|
o a
log: fix log -f slow path to actually follow history The revset created when -f was used with a slow path (for patterns and directories) did not actually contain any logic to enforce follow. Instead it was depending on the passed in subset to already be limited (which was limited to :. but not ::.). This fixes it by adding a '& ::.' to any -f log revset. hg log -f <file> is still broken, in that it can return results that aren't actually ancestors of the current file, but fixing that has major perf implications, so we'll deal with it later.
2014-12-06 01:27:32 +03:00
$ hg log -f d/a -T '{desc}' -G
linkrev: also adjust linkrev when bootstrapping 'follow' revset The follow revset (used by `hg log --follow`) now uses the new 'introrev' method to bootstrap its traversal. This catches issues from linkrev-shadowing of the changesets introducing the version of a file in source changeset. A new test has been added to display pathological cases. Another test is affected because it was meant to test this behavior but actually failed to do so for half of the output. The output are now similar.
2014-12-30 10:40:24 +03:00
@ c
log: fix log -f slow path to actually follow history The revset created when -f was used with a slow path (for patterns and directories) did not actually contain any logic to enforce follow. Instead it was depending on the passed in subset to already be limited (which was limited to :. but not ::.). This fixes it by adding a '& ::.' to any -f log revset. hg log -f <file> is still broken, in that it can return results that aren't actually ancestors of the current file, but fixing that has major perf implications, so we'll deal with it later.
2014-12-06 01:27:32 +03:00
|
o a
log: speed up hg log for untracked files (issue1340) 'hg log' on untracked files tends to be fairly slow. The root cause is that we end up using the 'slowpath' when we can't find a revlog for the files listed. This could happen if the file in question is an untracked file, or it is a directory. This diff tries to speed up 'hg log' (by avoiding the slowpath) for files if we can determine if that file is not (and was never) a directory. We use the previously added store.__contains__ methods to test if the directory exists (or existed) in the store. To avoid changing any existing semantics, this 'optimization' kicks in only when none of the files listed as arguments to the hg log command exist in the store.
2012-09-14 10:50:45 +04:00
$ cd ..
filectx.parents: enforce changeid of parent to be in own changectx ancestors Because of the way filenodes are computed, you can have multiple changesets "introducing" the same file revision. For example, in the changeset graph below, changeset 2 and 3 both change a file -to- and -from- the same content. o 3: content = new | | o 2: content = new |/ o 1: content = old In such cases, the file revision is create once, when 2 is added, and just reused for 3. So the file change in '3' (from "old" to "new)" has no linkrev pointing to it). We'll call this situation "linkrev-shadowing". As the linkrev is used for optimization purposes when walking a file history, the linkrev-shadowing results in an unexpected jump to another branch during such a walk.. This leads to multiple bugs with log, annotate and rename detection. One element to fix such bugs is to ensure that walking the file history sticks on the same topology as the changeset's history. For this purpose, we extend the logic in 'basefilectx.parents' so that it always defines the proper changeset to associate the parent file revision with. This "proper" changeset has to be an ancestor of the changeset associated with the child file revision. This logic is performed in the '_adjustlinkrev' function. This function is given the starting changeset and all the information regarding the parent file revision. If the linkrev for the file revision is an ancestor of the starting changeset, the linkrev is valid and will be used. If it is not, we detected a topological jump caused by linkrev shadowing, we are going to walk the ancestors of the starting changeset until we find one setting the file to the revision we are trying to create. The performance impact appears acceptable: - We are walking the changelog once for each filelog traversal (as there should be no overlap between searches), - changelog traversal itself is fairly cheap, compared to what is likely going to be perform on the result on the filelog traversal, - We only touch the manifest for ancestors touching the file, And such changesets are likely to be the one introducing the file. (except in pathological cases involving merge), - We use manifest diff instead of full manifest unpacking to check manifest content, so it does not involve applying multiple diffs in most case. - linkrev shadowing is not the common case. Tests for fixed issues in log, annotate and rename detection have been added. But this changeset does not solve all problems. It fixes -ancestry- computation, but if the linkrev-shadowed changesets is the starting one, we'll still get things wrong. We'll have to fix the bootstrapping of such operations in a later changeset. Also, the usage of `hg log FILE` without --follow still has issues with linkrev pointing to hidden changesets, because it relies on the `filelog` revset which implement its own traversal logic that is still to be fixed. Thanks goes to: - Matt Mackall: for nudging me in the right direction - Julien Cristau and Rémi Cardona: for keep telling me linkrev bug were an evolution show stopper for 3 years. - Durham Goode: for finding a new linkrev issue every few weeks - Mads Kiilerich: for that last rename bug who raise this topic over my anoyance limit.
2014-12-24 02:30:38 +03:00
hg log -f with linkrev pointing to another branch
-------------------------------------------------
create history with a filerev whose linkrev points to another branch
$ hg init branchedlinkrev
$ cd branchedlinkrev
$ echo 1 > a
$ hg commit -Am 'content1'
adding a
$ echo 2 > a
$ hg commit -m 'content2'
$ hg up --rev 'desc(content1)'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo unrelated > unrelated
$ hg commit -Am 'unrelated'
adding unrelated
$ hg graft -r 'desc(content2)'
grafting 1:2294ae80ad84 "content2"
$ echo 3 > a
$ hg commit -m 'content3'
$ hg log -G
@ changeset: 4:50b9b36e9c5d
| tag: tip
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: content3
|
o changeset: 3:15b2327059e5
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: content2
|
o changeset: 2:2029acd1168c
| parent: 0:ae0a3c9f9e95
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: unrelated
|
| o changeset: 1:2294ae80ad84
|/ user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: content2
|
o changeset: 0:ae0a3c9f9e95
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: content1
log -f on the file should list the graft result.
$ hg log -Gf a
@ changeset: 4:50b9b36e9c5d
| tag: tip
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: content3
|
o changeset: 3:15b2327059e5
graphmod: set default edge styles for ascii graphs (BC) Leaving regular parent edges set to |, grandparent edges set to : and missing parent edges set to end early. A sample graph: o changeset: 32:d06dffa21a31 |\ parent: 27:886ed638191b | : parent: 31:621d83e11f67 | : o : changeset: 31:621d83e11f67 |\: parent: 21:d42a756af44d | : parent: 30:6e11cd4b648f | : o : changeset: 30:6e11cd4b648f |\ \ parent: 28:44ecd0b9ae99 | ~ : parent: 29:cd9bb2be7593 | / o : changeset: 28:44ecd0b9ae99 |\ \ parent: 1:6db2ef61d156 | ~ : parent: 26:7f25b6c2f0b9 | / o : changeset: 26:7f25b6c2f0b9 |\ \ parent: 18:1aa84d96232a | | : parent: 25:91da8ed57247 | | : | o : changeset: 25:91da8ed57247 | |\: parent: 21:d42a756af44d | | : parent: 24:a9c19a3d96b7 | | : | o : changeset: 24:a9c19a3d96b7 | |\ \ parent: 0:e6eb3150255d | | ~ : parent: 23:a01cddf0766d | | / | o : changeset: 23:a01cddf0766d | |\ \ parent: 1:6db2ef61d156 | | ~ : parent: 22:e0d9cccacb5d | | / | o : changeset: 22:e0d9cccacb5d |/:/ parent: 18:1aa84d96232a | : parent: 21:d42a756af44d | : | o changeset: 21:d42a756af44d | |\ parent: 19:31ddc2c1573b | | | parent: 20:d30ed6450e32 | | | +---o changeset: 20:d30ed6450e32 | | | parent: 0:e6eb3150255d | | ~ parent: 18:1aa84d96232a | | | o changeset: 19:31ddc2c1573b | |\ parent: 15:1dda3f72782d | ~ ~ parent: 17:44765d7c06e0 | o changeset: 18:1aa84d96232a parent: 1:6db2ef61d156 parent: 15:1dda3f72782d
2016-03-23 23:34:47 +03:00
: user: test
: date: Thu Jan 01 00:00:00 1970 +0000
: summary: content2
:
filectx.parents: enforce changeid of parent to be in own changectx ancestors Because of the way filenodes are computed, you can have multiple changesets "introducing" the same file revision. For example, in the changeset graph below, changeset 2 and 3 both change a file -to- and -from- the same content. o 3: content = new | | o 2: content = new |/ o 1: content = old In such cases, the file revision is create once, when 2 is added, and just reused for 3. So the file change in '3' (from "old" to "new)" has no linkrev pointing to it). We'll call this situation "linkrev-shadowing". As the linkrev is used for optimization purposes when walking a file history, the linkrev-shadowing results in an unexpected jump to another branch during such a walk.. This leads to multiple bugs with log, annotate and rename detection. One element to fix such bugs is to ensure that walking the file history sticks on the same topology as the changeset's history. For this purpose, we extend the logic in 'basefilectx.parents' so that it always defines the proper changeset to associate the parent file revision with. This "proper" changeset has to be an ancestor of the changeset associated with the child file revision. This logic is performed in the '_adjustlinkrev' function. This function is given the starting changeset and all the information regarding the parent file revision. If the linkrev for the file revision is an ancestor of the starting changeset, the linkrev is valid and will be used. If it is not, we detected a topological jump caused by linkrev shadowing, we are going to walk the ancestors of the starting changeset until we find one setting the file to the revision we are trying to create. The performance impact appears acceptable: - We are walking the changelog once for each filelog traversal (as there should be no overlap between searches), - changelog traversal itself is fairly cheap, compared to what is likely going to be perform on the result on the filelog traversal, - We only touch the manifest for ancestors touching the file, And such changesets are likely to be the one introducing the file. (except in pathological cases involving merge), - We use manifest diff instead of full manifest unpacking to check manifest content, so it does not involve applying multiple diffs in most case. - linkrev shadowing is not the common case. Tests for fixed issues in log, annotate and rename detection have been added. But this changeset does not solve all problems. It fixes -ancestry- computation, but if the linkrev-shadowed changesets is the starting one, we'll still get things wrong. We'll have to fix the bootstrapping of such operations in a later changeset. Also, the usage of `hg log FILE` without --follow still has issues with linkrev pointing to hidden changesets, because it relies on the `filelog` revset which implement its own traversal logic that is still to be fixed. Thanks goes to: - Matt Mackall: for nudging me in the right direction - Julien Cristau and Rémi Cardona: for keep telling me linkrev bug were an evolution show stopper for 3 years. - Durham Goode: for finding a new linkrev issue every few weeks - Mads Kiilerich: for that last rename bug who raise this topic over my anoyance limit.
2014-12-24 02:30:38 +03:00
o changeset: 0:ae0a3c9f9e95
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: content1
plain log lists the original version
(XXX we should probably list both)
$ hg log -G a
@ changeset: 4:50b9b36e9c5d
graphmod: set default edge styles for ascii graphs (BC) Leaving regular parent edges set to |, grandparent edges set to : and missing parent edges set to end early. A sample graph: o changeset: 32:d06dffa21a31 |\ parent: 27:886ed638191b | : parent: 31:621d83e11f67 | : o : changeset: 31:621d83e11f67 |\: parent: 21:d42a756af44d | : parent: 30:6e11cd4b648f | : o : changeset: 30:6e11cd4b648f |\ \ parent: 28:44ecd0b9ae99 | ~ : parent: 29:cd9bb2be7593 | / o : changeset: 28:44ecd0b9ae99 |\ \ parent: 1:6db2ef61d156 | ~ : parent: 26:7f25b6c2f0b9 | / o : changeset: 26:7f25b6c2f0b9 |\ \ parent: 18:1aa84d96232a | | : parent: 25:91da8ed57247 | | : | o : changeset: 25:91da8ed57247 | |\: parent: 21:d42a756af44d | | : parent: 24:a9c19a3d96b7 | | : | o : changeset: 24:a9c19a3d96b7 | |\ \ parent: 0:e6eb3150255d | | ~ : parent: 23:a01cddf0766d | | / | o : changeset: 23:a01cddf0766d | |\ \ parent: 1:6db2ef61d156 | | ~ : parent: 22:e0d9cccacb5d | | / | o : changeset: 22:e0d9cccacb5d |/:/ parent: 18:1aa84d96232a | : parent: 21:d42a756af44d | : | o changeset: 21:d42a756af44d | |\ parent: 19:31ddc2c1573b | | | parent: 20:d30ed6450e32 | | | +---o changeset: 20:d30ed6450e32 | | | parent: 0:e6eb3150255d | | ~ parent: 18:1aa84d96232a | | | o changeset: 19:31ddc2c1573b | |\ parent: 15:1dda3f72782d | ~ ~ parent: 17:44765d7c06e0 | o changeset: 18:1aa84d96232a parent: 1:6db2ef61d156 parent: 15:1dda3f72782d
2016-03-23 23:34:47 +03:00
: tag: tip
: user: test
: date: Thu Jan 01 00:00:00 1970 +0000
: summary: content3
:
: o changeset: 1:2294ae80ad84
:/ user: test
: date: Thu Jan 01 00:00:00 1970 +0000
: summary: content2
:
filectx.parents: enforce changeid of parent to be in own changectx ancestors Because of the way filenodes are computed, you can have multiple changesets "introducing" the same file revision. For example, in the changeset graph below, changeset 2 and 3 both change a file -to- and -from- the same content. o 3: content = new | | o 2: content = new |/ o 1: content = old In such cases, the file revision is create once, when 2 is added, and just reused for 3. So the file change in '3' (from "old" to "new)" has no linkrev pointing to it). We'll call this situation "linkrev-shadowing". As the linkrev is used for optimization purposes when walking a file history, the linkrev-shadowing results in an unexpected jump to another branch during such a walk.. This leads to multiple bugs with log, annotate and rename detection. One element to fix such bugs is to ensure that walking the file history sticks on the same topology as the changeset's history. For this purpose, we extend the logic in 'basefilectx.parents' so that it always defines the proper changeset to associate the parent file revision with. This "proper" changeset has to be an ancestor of the changeset associated with the child file revision. This logic is performed in the '_adjustlinkrev' function. This function is given the starting changeset and all the information regarding the parent file revision. If the linkrev for the file revision is an ancestor of the starting changeset, the linkrev is valid and will be used. If it is not, we detected a topological jump caused by linkrev shadowing, we are going to walk the ancestors of the starting changeset until we find one setting the file to the revision we are trying to create. The performance impact appears acceptable: - We are walking the changelog once for each filelog traversal (as there should be no overlap between searches), - changelog traversal itself is fairly cheap, compared to what is likely going to be perform on the result on the filelog traversal, - We only touch the manifest for ancestors touching the file, And such changesets are likely to be the one introducing the file. (except in pathological cases involving merge), - We use manifest diff instead of full manifest unpacking to check manifest content, so it does not involve applying multiple diffs in most case. - linkrev shadowing is not the common case. Tests for fixed issues in log, annotate and rename detection have been added. But this changeset does not solve all problems. It fixes -ancestry- computation, but if the linkrev-shadowed changesets is the starting one, we'll still get things wrong. We'll have to fix the bootstrapping of such operations in a later changeset. Also, the usage of `hg log FILE` without --follow still has issues with linkrev pointing to hidden changesets, because it relies on the `filelog` revset which implement its own traversal logic that is still to be fixed. Thanks goes to: - Matt Mackall: for nudging me in the right direction - Julien Cristau and Rémi Cardona: for keep telling me linkrev bug were an evolution show stopper for 3 years. - Durham Goode: for finding a new linkrev issue every few weeks - Mads Kiilerich: for that last rename bug who raise this topic over my anoyance limit.
2014-12-24 02:30:38 +03:00
o changeset: 0:ae0a3c9f9e95
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: content1
linkrev: also adjust linkrev when bootstrapping 'follow' revset The follow revset (used by `hg log --follow`) now uses the new 'introrev' method to bootstrap its traversal. This catches issues from linkrev-shadowing of the changesets introducing the version of a file in source changeset. A new test has been added to display pathological cases. Another test is affected because it was meant to test this behavior but actually failed to do so for half of the output. The output are now similar.
2014-12-30 10:40:24 +03:00
hg log -f from the grafted changeset
(The bootstrap should properly take the topology in account)
$ hg up 'desc(content3)^'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg log -Gf a
@ changeset: 3:15b2327059e5
graphmod: set default edge styles for ascii graphs (BC) Leaving regular parent edges set to |, grandparent edges set to : and missing parent edges set to end early. A sample graph: o changeset: 32:d06dffa21a31 |\ parent: 27:886ed638191b | : parent: 31:621d83e11f67 | : o : changeset: 31:621d83e11f67 |\: parent: 21:d42a756af44d | : parent: 30:6e11cd4b648f | : o : changeset: 30:6e11cd4b648f |\ \ parent: 28:44ecd0b9ae99 | ~ : parent: 29:cd9bb2be7593 | / o : changeset: 28:44ecd0b9ae99 |\ \ parent: 1:6db2ef61d156 | ~ : parent: 26:7f25b6c2f0b9 | / o : changeset: 26:7f25b6c2f0b9 |\ \ parent: 18:1aa84d96232a | | : parent: 25:91da8ed57247 | | : | o : changeset: 25:91da8ed57247 | |\: parent: 21:d42a756af44d | | : parent: 24:a9c19a3d96b7 | | : | o : changeset: 24:a9c19a3d96b7 | |\ \ parent: 0:e6eb3150255d | | ~ : parent: 23:a01cddf0766d | | / | o : changeset: 23:a01cddf0766d | |\ \ parent: 1:6db2ef61d156 | | ~ : parent: 22:e0d9cccacb5d | | / | o : changeset: 22:e0d9cccacb5d |/:/ parent: 18:1aa84d96232a | : parent: 21:d42a756af44d | : | o changeset: 21:d42a756af44d | |\ parent: 19:31ddc2c1573b | | | parent: 20:d30ed6450e32 | | | +---o changeset: 20:d30ed6450e32 | | | parent: 0:e6eb3150255d | | ~ parent: 18:1aa84d96232a | | | o changeset: 19:31ddc2c1573b | |\ parent: 15:1dda3f72782d | ~ ~ parent: 17:44765d7c06e0 | o changeset: 18:1aa84d96232a parent: 1:6db2ef61d156 parent: 15:1dda3f72782d
2016-03-23 23:34:47 +03:00
: user: test
: date: Thu Jan 01 00:00:00 1970 +0000
: summary: content2
:
linkrev: also adjust linkrev when bootstrapping 'follow' revset The follow revset (used by `hg log --follow`) now uses the new 'introrev' method to bootstrap its traversal. This catches issues from linkrev-shadowing of the changesets introducing the version of a file in source changeset. A new test has been added to display pathological cases. Another test is affected because it was meant to test this behavior but actually failed to do so for half of the output. The output are now similar.
2014-12-30 10:40:24 +03:00
o changeset: 0:ae0a3c9f9e95
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: content1
linkrev: work around linkrev to filtered entry in 'filelog' revset This revset is used by 'hg log FILENAME'. This prevent bugs when used on a repository with hidden revisions. Instead of just discarding file revisions whose linkrevs point to filtered revisions, we put them aside and post-process them trying to find a non-filtered introduction. See inline documentation for details about how it works. This only fixes some of the problems. Once again, more will be needed when we can cannot rely on child revisions of a file to find linkrev-shadowned revisions. A test is added for 'hg log' catching such cases.
2014-12-30 04:23:16 +03:00
Test that we use the first non-hidden changeset in that case.
(hide the changeset)
$ hg log -T '{node}\n' -r 1
2294ae80ad8447bc78383182eeac50cb049df623
$ hg debugobsolete 2294ae80ad8447bc78383182eeac50cb049df623
debugobsolete: also report the number of obsoleted changesets This seems useful to have the number of obsoleted changesets when calling debugobsolete.
2017-07-16 03:33:14 +03:00
obsoleted 1 changesets
linkrev: work around linkrev to filtered entry in 'filelog' revset This revset is used by 'hg log FILENAME'. This prevent bugs when used on a repository with hidden revisions. Instead of just discarding file revisions whose linkrevs point to filtered revisions, we put them aside and post-process them trying to find a non-filtered introduction. See inline documentation for details about how it works. This only fixes some of the problems. Once again, more will be needed when we can cannot rely on child revisions of a file to find linkrev-shadowned revisions. A test is added for 'hg log' catching such cases.
2014-12-30 04:23:16 +03:00
$ hg log -G
o changeset: 4:50b9b36e9c5d
| tag: tip
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: content3
|
@ changeset: 3:15b2327059e5
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: content2
|
o changeset: 2:2029acd1168c
| parent: 0:ae0a3c9f9e95
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: unrelated
|
o changeset: 0:ae0a3c9f9e95
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: content1
Check that log on the file does not drop the file revision.
$ hg log -G a
o changeset: 4:50b9b36e9c5d
| tag: tip
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: content3
|
@ changeset: 3:15b2327059e5
graphmod: set default edge styles for ascii graphs (BC) Leaving regular parent edges set to |, grandparent edges set to : and missing parent edges set to end early. A sample graph: o changeset: 32:d06dffa21a31 |\ parent: 27:886ed638191b | : parent: 31:621d83e11f67 | : o : changeset: 31:621d83e11f67 |\: parent: 21:d42a756af44d | : parent: 30:6e11cd4b648f | : o : changeset: 30:6e11cd4b648f |\ \ parent: 28:44ecd0b9ae99 | ~ : parent: 29:cd9bb2be7593 | / o : changeset: 28:44ecd0b9ae99 |\ \ parent: 1:6db2ef61d156 | ~ : parent: 26:7f25b6c2f0b9 | / o : changeset: 26:7f25b6c2f0b9 |\ \ parent: 18:1aa84d96232a | | : parent: 25:91da8ed57247 | | : | o : changeset: 25:91da8ed57247 | |\: parent: 21:d42a756af44d | | : parent: 24:a9c19a3d96b7 | | : | o : changeset: 24:a9c19a3d96b7 | |\ \ parent: 0:e6eb3150255d | | ~ : parent: 23:a01cddf0766d | | / | o : changeset: 23:a01cddf0766d | |\ \ parent: 1:6db2ef61d156 | | ~ : parent: 22:e0d9cccacb5d | | / | o : changeset: 22:e0d9cccacb5d |/:/ parent: 18:1aa84d96232a | : parent: 21:d42a756af44d | : | o changeset: 21:d42a756af44d | |\ parent: 19:31ddc2c1573b | | | parent: 20:d30ed6450e32 | | | +---o changeset: 20:d30ed6450e32 | | | parent: 0:e6eb3150255d | | ~ parent: 18:1aa84d96232a | | | o changeset: 19:31ddc2c1573b | |\ parent: 15:1dda3f72782d | ~ ~ parent: 17:44765d7c06e0 | o changeset: 18:1aa84d96232a parent: 1:6db2ef61d156 parent: 15:1dda3f72782d
2016-03-23 23:34:47 +03:00
: user: test
: date: Thu Jan 01 00:00:00 1970 +0000
: summary: content2
:
linkrev: work around linkrev to filtered entry in 'filelog' revset This revset is used by 'hg log FILENAME'. This prevent bugs when used on a repository with hidden revisions. Instead of just discarding file revisions whose linkrevs point to filtered revisions, we put them aside and post-process them trying to find a non-filtered introduction. See inline documentation for details about how it works. This only fixes some of the problems. Once again, more will be needed when we can cannot rely on child revisions of a file to find linkrev-shadowned revisions. A test is added for 'hg log' catching such cases.
2014-12-30 04:23:16 +03:00
o changeset: 0:ae0a3c9f9e95
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: content1
linkrev-filelog: handle filtered linkrev with no visible children (issue4307) If the file revision with a filtered linkrev does not have any (unfiltered) children, we cannot use it to bound the search for another introduction. Instead, we have to look at the file revision used by each head changeset. If one of them uses this file revision, we know there is another occurrence and we have a starting point. See inline comments for details. Adding some kind of permanent reference of all the introductions of a file revision instead of just the first one would be much better. But this is more difficult. I hope to take that into account in the next repository format.
2014-12-30 05:35:23 +03:00
Even when a head revision is linkrev-shadowed.
$ hg log -T '{node}\n' -r 4
50b9b36e9c5df2c6fc6dcefa8ad0da929e84aed2
$ hg debugobsolete 50b9b36e9c5df2c6fc6dcefa8ad0da929e84aed2
debugobsolete: also report the number of obsoleted changesets This seems useful to have the number of obsoleted changesets when calling debugobsolete.
2017-07-16 03:33:14 +03:00
obsoleted 1 changesets
linkrev-filelog: handle filtered linkrev with no visible children (issue4307) If the file revision with a filtered linkrev does not have any (unfiltered) children, we cannot use it to bound the search for another introduction. Instead, we have to look at the file revision used by each head changeset. If one of them uses this file revision, we know there is another occurrence and we have a starting point. See inline comments for details. Adding some kind of permanent reference of all the introductions of a file revision instead of just the first one would be much better. But this is more difficult. I hope to take that into account in the next repository format.
2014-12-30 05:35:23 +03:00
$ hg log -G a
@ changeset: 3:15b2327059e5
graphmod: set default edge styles for ascii graphs (BC) Leaving regular parent edges set to |, grandparent edges set to : and missing parent edges set to end early. A sample graph: o changeset: 32:d06dffa21a31 |\ parent: 27:886ed638191b | : parent: 31:621d83e11f67 | : o : changeset: 31:621d83e11f67 |\: parent: 21:d42a756af44d | : parent: 30:6e11cd4b648f | : o : changeset: 30:6e11cd4b648f |\ \ parent: 28:44ecd0b9ae99 | ~ : parent: 29:cd9bb2be7593 | / o : changeset: 28:44ecd0b9ae99 |\ \ parent: 1:6db2ef61d156 | ~ : parent: 26:7f25b6c2f0b9 | / o : changeset: 26:7f25b6c2f0b9 |\ \ parent: 18:1aa84d96232a | | : parent: 25:91da8ed57247 | | : | o : changeset: 25:91da8ed57247 | |\: parent: 21:d42a756af44d | | : parent: 24:a9c19a3d96b7 | | : | o : changeset: 24:a9c19a3d96b7 | |\ \ parent: 0:e6eb3150255d | | ~ : parent: 23:a01cddf0766d | | / | o : changeset: 23:a01cddf0766d | |\ \ parent: 1:6db2ef61d156 | | ~ : parent: 22:e0d9cccacb5d | | / | o : changeset: 22:e0d9cccacb5d |/:/ parent: 18:1aa84d96232a | : parent: 21:d42a756af44d | : | o changeset: 21:d42a756af44d | |\ parent: 19:31ddc2c1573b | | | parent: 20:d30ed6450e32 | | | +---o changeset: 20:d30ed6450e32 | | | parent: 0:e6eb3150255d | | ~ parent: 18:1aa84d96232a | | | o changeset: 19:31ddc2c1573b | |\ parent: 15:1dda3f72782d | ~ ~ parent: 17:44765d7c06e0 | o changeset: 18:1aa84d96232a parent: 1:6db2ef61d156 parent: 15:1dda3f72782d
2016-03-23 23:34:47 +03:00
: tag: tip
: user: test
: date: Thu Jan 01 00:00:00 1970 +0000
: summary: content2
:
linkrev-filelog: handle filtered linkrev with no visible children (issue4307) If the file revision with a filtered linkrev does not have any (unfiltered) children, we cannot use it to bound the search for another introduction. Instead, we have to look at the file revision used by each head changeset. If one of them uses this file revision, we know there is another occurrence and we have a starting point. See inline comments for details. Adding some kind of permanent reference of all the introductions of a file revision instead of just the first one would be much better. But this is more difficult. I hope to take that into account in the next repository format.
2014-12-30 05:35:23 +03:00
o changeset: 0:ae0a3c9f9e95
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: content1
filectx.parents: enforce changeid of parent to be in own changectx ancestors Because of the way filenodes are computed, you can have multiple changesets "introducing" the same file revision. For example, in the changeset graph below, changeset 2 and 3 both change a file -to- and -from- the same content. o 3: content = new | | o 2: content = new |/ o 1: content = old In such cases, the file revision is create once, when 2 is added, and just reused for 3. So the file change in '3' (from "old" to "new)" has no linkrev pointing to it). We'll call this situation "linkrev-shadowing". As the linkrev is used for optimization purposes when walking a file history, the linkrev-shadowing results in an unexpected jump to another branch during such a walk.. This leads to multiple bugs with log, annotate and rename detection. One element to fix such bugs is to ensure that walking the file history sticks on the same topology as the changeset's history. For this purpose, we extend the logic in 'basefilectx.parents' so that it always defines the proper changeset to associate the parent file revision with. This "proper" changeset has to be an ancestor of the changeset associated with the child file revision. This logic is performed in the '_adjustlinkrev' function. This function is given the starting changeset and all the information regarding the parent file revision. If the linkrev for the file revision is an ancestor of the starting changeset, the linkrev is valid and will be used. If it is not, we detected a topological jump caused by linkrev shadowing, we are going to walk the ancestors of the starting changeset until we find one setting the file to the revision we are trying to create. The performance impact appears acceptable: - We are walking the changelog once for each filelog traversal (as there should be no overlap between searches), - changelog traversal itself is fairly cheap, compared to what is likely going to be perform on the result on the filelog traversal, - We only touch the manifest for ancestors touching the file, And such changesets are likely to be the one introducing the file. (except in pathological cases involving merge), - We use manifest diff instead of full manifest unpacking to check manifest content, so it does not involve applying multiple diffs in most case. - linkrev shadowing is not the common case. Tests for fixed issues in log, annotate and rename detection have been added. But this changeset does not solve all problems. It fixes -ancestry- computation, but if the linkrev-shadowed changesets is the starting one, we'll still get things wrong. We'll have to fix the bootstrapping of such operations in a later changeset. Also, the usage of `hg log FILE` without --follow still has issues with linkrev pointing to hidden changesets, because it relies on the `filelog` revset which implement its own traversal logic that is still to be fixed. Thanks goes to: - Matt Mackall: for nudging me in the right direction - Julien Cristau and Rémi Cardona: for keep telling me linkrev bug were an evolution show stopper for 3 years. - Durham Goode: for finding a new linkrev issue every few weeks - Mads Kiilerich: for that last rename bug who raise this topic over my anoyance limit.
2014-12-24 02:30:38 +03:00
$ cd ..
revset-filelog: handle hidden linkrev for file missing for head (issue4490) The fix for linkrev pointing to hidden revision was crashing when the file was missing from head's manifest. We now properly handle this case. (yes I feel silly)
2015-01-06 22:23:38 +03:00
Even when the file revision is missing from some head:
$ hg init issue4490
$ cd issue4490
$ echo '[experimental]' >> .hg/hgrc
config: use 'experimental.evolution.create-markers' Extract 'experimental.evolution' = createmarkers as 'experimental.evolution.createmarkers'. We keep the new option in the 'experimental.evolution' namespace in order to stay coherent with other options ('experimental.evolution.bundle-obsmarker' and 'experimental.evolution.track-operation') ease the renaming as possibly 'evolution.createmarkers'. Differential Revision: https://phab.mercurial-scm.org/D1149
2017-09-28 20:19:06 +03:00
$ echo 'evolution.createmarkers=True' >> .hg/hgrc
revset-filelog: handle hidden linkrev for file missing for head (issue4490) The fix for linkrev pointing to hidden revision was crashing when the file was missing from head's manifest. We now properly handle this case. (yes I feel silly)
2015-01-06 22:23:38 +03:00
$ echo a > a
$ hg ci -Am0
adding a
$ echo b > b
$ hg ci -Am1
adding b
$ echo B > b
$ hg ci --amend -m 1
$ hg up 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo c > c
$ hg ci -Am2
adding c
$ hg up 'head() and not .'
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg log -G
cmdutil: remove the redundant commit during amend There was an extra commit made during the amend operation to track the changes to the working copy. However, this logic was written a long time back and newer API's make this extra commit redundant. Therefore, I am removing the extra commit. After this change, I noticed that - Execution time of the cmdutil.amend improved by over 40%. - Execution time of "hg commit --amend" improved by over 20%. Test Plan: I ensured that the all the hg tests passed after the change. I had to fix a few tests which were aware of the extra commit made during the amend. Differential Revision: https://phab.mercurial-scm.org/D636
2017-09-01 22:34:36 +03:00
o changeset: 3:db815d6d32e6
revset-filelog: handle hidden linkrev for file missing for head (issue4490) The fix for linkrev pointing to hidden revision was crashing when the file was missing from head's manifest. We now properly handle this case. (yes I feel silly)
2015-01-06 22:23:38 +03:00
| tag: tip
| parent: 0:f7b1eb17ad24
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: 2
|
cmdutil: remove the redundant commit during amend There was an extra commit made during the amend operation to track the changes to the working copy. However, this logic was written a long time back and newer API's make this extra commit redundant. Therefore, I am removing the extra commit. After this change, I noticed that - Execution time of the cmdutil.amend improved by over 40%. - Execution time of "hg commit --amend" improved by over 20%. Test Plan: I ensured that the all the hg tests passed after the change. I had to fix a few tests which were aware of the extra commit made during the amend. Differential Revision: https://phab.mercurial-scm.org/D636
2017-09-01 22:34:36 +03:00
| @ changeset: 2:9bc8ce7f9356
revset-filelog: handle hidden linkrev for file missing for head (issue4490) The fix for linkrev pointing to hidden revision was crashing when the file was missing from head's manifest. We now properly handle this case. (yes I feel silly)
2015-01-06 22:23:38 +03:00
|/ parent: 0:f7b1eb17ad24
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: 1
|
o changeset: 0:f7b1eb17ad24
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: 0
$ hg log -f -G b
cmdutil: remove the redundant commit during amend There was an extra commit made during the amend operation to track the changes to the working copy. However, this logic was written a long time back and newer API's make this extra commit redundant. Therefore, I am removing the extra commit. After this change, I noticed that - Execution time of the cmdutil.amend improved by over 40%. - Execution time of "hg commit --amend" improved by over 20%. Test Plan: I ensured that the all the hg tests passed after the change. I had to fix a few tests which were aware of the extra commit made during the amend. Differential Revision: https://phab.mercurial-scm.org/D636
2017-09-01 22:34:36 +03:00
@ changeset: 2:9bc8ce7f9356
revset-filelog: handle hidden linkrev for file missing for head (issue4490) The fix for linkrev pointing to hidden revision was crashing when the file was missing from head's manifest. We now properly handle this case. (yes I feel silly)
2015-01-06 22:23:38 +03:00
| parent: 0:f7b1eb17ad24
graphmod: set default edge styles for ascii graphs (BC) Leaving regular parent edges set to |, grandparent edges set to : and missing parent edges set to end early. A sample graph: o changeset: 32:d06dffa21a31 |\ parent: 27:886ed638191b | : parent: 31:621d83e11f67 | : o : changeset: 31:621d83e11f67 |\: parent: 21:d42a756af44d | : parent: 30:6e11cd4b648f | : o : changeset: 30:6e11cd4b648f |\ \ parent: 28:44ecd0b9ae99 | ~ : parent: 29:cd9bb2be7593 | / o : changeset: 28:44ecd0b9ae99 |\ \ parent: 1:6db2ef61d156 | ~ : parent: 26:7f25b6c2f0b9 | / o : changeset: 26:7f25b6c2f0b9 |\ \ parent: 18:1aa84d96232a | | : parent: 25:91da8ed57247 | | : | o : changeset: 25:91da8ed57247 | |\: parent: 21:d42a756af44d | | : parent: 24:a9c19a3d96b7 | | : | o : changeset: 24:a9c19a3d96b7 | |\ \ parent: 0:e6eb3150255d | | ~ : parent: 23:a01cddf0766d | | / | o : changeset: 23:a01cddf0766d | |\ \ parent: 1:6db2ef61d156 | | ~ : parent: 22:e0d9cccacb5d | | / | o : changeset: 22:e0d9cccacb5d |/:/ parent: 18:1aa84d96232a | : parent: 21:d42a756af44d | : | o changeset: 21:d42a756af44d | |\ parent: 19:31ddc2c1573b | | | parent: 20:d30ed6450e32 | | | +---o changeset: 20:d30ed6450e32 | | | parent: 0:e6eb3150255d | | ~ parent: 18:1aa84d96232a | | | o changeset: 19:31ddc2c1573b | |\ parent: 15:1dda3f72782d | ~ ~ parent: 17:44765d7c06e0 | o changeset: 18:1aa84d96232a parent: 1:6db2ef61d156 parent: 15:1dda3f72782d
2016-03-23 23:34:47 +03:00
~ user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: 1
revset-filelog: handle hidden linkrev for file missing for head (issue4490) The fix for linkrev pointing to hidden revision was crashing when the file was missing from head's manifest. We now properly handle this case. (yes I feel silly)
2015-01-06 22:23:38 +03:00
$ hg log -G b
cmdutil: remove the redundant commit during amend There was an extra commit made during the amend operation to track the changes to the working copy. However, this logic was written a long time back and newer API's make this extra commit redundant. Therefore, I am removing the extra commit. After this change, I noticed that - Execution time of the cmdutil.amend improved by over 40%. - Execution time of "hg commit --amend" improved by over 20%. Test Plan: I ensured that the all the hg tests passed after the change. I had to fix a few tests which were aware of the extra commit made during the amend. Differential Revision: https://phab.mercurial-scm.org/D636
2017-09-01 22:34:36 +03:00
@ changeset: 2:9bc8ce7f9356
revset-filelog: handle hidden linkrev for file missing for head (issue4490) The fix for linkrev pointing to hidden revision was crashing when the file was missing from head's manifest. We now properly handle this case. (yes I feel silly)
2015-01-06 22:23:38 +03:00
| parent: 0:f7b1eb17ad24
graphmod: set default edge styles for ascii graphs (BC) Leaving regular parent edges set to |, grandparent edges set to : and missing parent edges set to end early. A sample graph: o changeset: 32:d06dffa21a31 |\ parent: 27:886ed638191b | : parent: 31:621d83e11f67 | : o : changeset: 31:621d83e11f67 |\: parent: 21:d42a756af44d | : parent: 30:6e11cd4b648f | : o : changeset: 30:6e11cd4b648f |\ \ parent: 28:44ecd0b9ae99 | ~ : parent: 29:cd9bb2be7593 | / o : changeset: 28:44ecd0b9ae99 |\ \ parent: 1:6db2ef61d156 | ~ : parent: 26:7f25b6c2f0b9 | / o : changeset: 26:7f25b6c2f0b9 |\ \ parent: 18:1aa84d96232a | | : parent: 25:91da8ed57247 | | : | o : changeset: 25:91da8ed57247 | |\: parent: 21:d42a756af44d | | : parent: 24:a9c19a3d96b7 | | : | o : changeset: 24:a9c19a3d96b7 | |\ \ parent: 0:e6eb3150255d | | ~ : parent: 23:a01cddf0766d | | / | o : changeset: 23:a01cddf0766d | |\ \ parent: 1:6db2ef61d156 | | ~ : parent: 22:e0d9cccacb5d | | / | o : changeset: 22:e0d9cccacb5d |/:/ parent: 18:1aa84d96232a | : parent: 21:d42a756af44d | : | o changeset: 21:d42a756af44d | |\ parent: 19:31ddc2c1573b | | | parent: 20:d30ed6450e32 | | | +---o changeset: 20:d30ed6450e32 | | | parent: 0:e6eb3150255d | | ~ parent: 18:1aa84d96232a | | | o changeset: 19:31ddc2c1573b | |\ parent: 15:1dda3f72782d | ~ ~ parent: 17:44765d7c06e0 | o changeset: 18:1aa84d96232a parent: 1:6db2ef61d156 parent: 15:1dda3f72782d
2016-03-23 23:34:47 +03:00
~ user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: 1
linkrev: use the right manifest content when adjusting linrev (issue4499) When the manifest revision is stored as a delta against a non-parent revision, '_adjustlinkrev' could miss some file update because it was using the delta only. We now use the 'fastread' method that uses the delta only when it makes sense. A test showcasing on the of possible issue have been added.
2015-01-15 04:21:09 +03:00
$ cd ..
Check proper report when the manifest changes but not the file issue4499
------------------------------------------------------------------------
$ hg init issue4499
$ cd issue4499
$ for f in A B C D F E G H I J K L M N O P Q R S T U; do
> echo 1 > $f;
> hg add $f;
> done
$ hg commit -m 'A1B1C1'
$ echo 2 > A
$ echo 2 > B
$ echo 2 > C
$ hg commit -m 'A2B2C2'
$ hg up 0
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo 3 > A
$ echo 2 > B
$ echo 2 > C
$ hg commit -m 'A3B2C2'
$ hg log -G
@ changeset: 2:fe5fc3d0eb17
| tag: tip
| parent: 0:abf4f0e38563
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: A3B2C2
|
| o changeset: 1:07dcc6b312c0
|/ user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: A2B2C2
|
o changeset: 0:abf4f0e38563
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: A1B1C1
Log -f on B should reports current changesets
$ hg log -fG B
@ changeset: 2:fe5fc3d0eb17
| tag: tip
| parent: 0:abf4f0e38563
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: A3B2C2
|
o changeset: 0:abf4f0e38563
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: A1B1C1
$ cd ..
Reference in New Issue Copy Permalink