facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-06 23:07:18 +03:00
Code Issues Projects Releases Wiki Activity
77e09b4e47
sapling/eden/scm/tests/test-identify.t

156 lines
2.9 KiB
Perl
Raw Normal View History

mark all tests requiring Python 2 Summary: This diff marks **ALL** mercurial tests requiring Python 2 feature. After you fixes some tests, simply remove the `py2` feature requirement and that tests will be continuously run after your diff is landed. To bypass this feature requirement, run the tests command with `HGTEST_FORCE_PY2=1`. For example: ``` HGTEST_FORCE_PY2=1 buck test //eden/scm/tests:hg_run_tests ``` or ``` HGTEST_FORCE_PY2=1 python run-tests.py ``` ---- Basically this diff are created with the following commands: ``` $ sed -i 's/import feature\(.*\)$/import feature\1\n\nfeature.require(["py2"])/' test-*-t.py $ sed -i '1s/^/#require py2\n/' test-*.t $ ls | grep -P "^test.*(?<\!-t)\.py$" > list && vim -p $(cat list) # manually adding feature requires for these Python tests. ``` (Note: this ignores all push blocking failures!) ignore-conflict-markers Reviewed By: singhsrb Differential Revision: D19655148 fbshipit-source-id: 985e3ccb4010cc559049f1d89f8909bc2d9b5e20
2020-01-31 05:40:49 +03:00
#require py2
tests: enable chg for 572 tests Summary: Add `#chg-compatible` to 572 tests that seem to pass with chg enabled. This should make them run faster. Reviewed By: xavierd Differential Revision: D18870507 fbshipit-source-id: fe895e733efffc9286cd3d17c7a156c803124395
2019-12-10 02:24:31 +03:00
#chg-compatible
tests: replace exit 80 with #require
2014-08-06 20:43:59 +04:00
#require serve
tests: convert some 'hghave no-outer-repo' to #if In some places we instead use 'hg init' to create a well-known outer repo without any special extensions or other config settings.
2012-06-21 01:41:21 +04:00
#if no-outer-repo
tests: unify test-identify
2010-08-12 14:49:58 +04:00
no repo
$ hg id
Merge with stable
2010-08-30 00:55:37 +04:00
abort: there is no Mercurial repository here (.hg not found)
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
tests: unify test-identify
2010-08-12 14:49:58 +04:00
tests: convert some 'hghave no-outer-repo' to #if In some places we instead use 'hg init' to create a well-known outer repo without any special extensions or other config settings.
2012-06-21 01:41:21 +04:00
#endif
tests: unify test-identify
2010-08-12 14:49:58 +04:00
create repo
$ hg init test
$ cd test
$ echo a > a
$ hg ci -Ama
adding a
basic id usage
$ hg id
tags: remove tip tag Summary: In a future diff we'll be removing tags. The most prevalent tag is 'tip', which shows up in a ton of test output. Let's drop that tag first, so we can safely update the tests before we drop tags entirely. Reviewed By: xavierd Differential Revision: D18995058 fbshipit-source-id: 8c63710cd4ed567ea24e32724b8660f9006a61f1
2019-12-18 00:45:17 +03:00
cb9a9f314b8b
tests: unify test-identify
2010-08-12 14:49:58 +04:00
$ hg id --debug
tags: remove tip tag Summary: In a future diff we'll be removing tags. The most prevalent tag is 'tip', which shows up in a ton of test output. Let's drop that tag first, so we can safely update the tests before we drop tags entirely. Reviewed By: xavierd Differential Revision: D18995058 fbshipit-source-id: 8c63710cd4ed567ea24e32724b8660f9006a61f1
2019-12-18 00:45:17 +03:00
cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b
tests: unify test-identify
2010-08-12 14:49:58 +04:00
$ hg id -q
cb9a9f314b8b
$ hg id -v
tags: remove tip tag Summary: In a future diff we'll be removing tags. The most prevalent tag is 'tip', which shows up in a ton of test output. Let's drop that tag first, so we can safely update the tests before we drop tags entirely. Reviewed By: xavierd Differential Revision: D18995058 fbshipit-source-id: 8c63710cd4ed567ea24e32724b8660f9006a61f1
2019-12-18 00:45:17 +03:00
cb9a9f314b8b
tests: unify test-identify
2010-08-12 14:49:58 +04:00
with options
$ hg id -r.
tags: remove tip tag Summary: In a future diff we'll be removing tags. The most prevalent tag is 'tip', which shows up in a ton of test output. Let's drop that tag first, so we can safely update the tests before we drop tags entirely. Reviewed By: xavierd Differential Revision: D18995058 fbshipit-source-id: 8c63710cd4ed567ea24e32724b8660f9006a61f1
2019-12-18 00:45:17 +03:00
cb9a9f314b8b
tests: unify test-identify
2010-08-12 14:49:58 +04:00
$ hg id -n
0
$ hg id -b
default
$ hg id -i
cb9a9f314b8b
$ hg id -n -t -b -i
tags: remove tip tag Summary: In a future diff we'll be removing tags. The most prevalent tag is 'tip', which shows up in a ton of test output. Let's drop that tag first, so we can safely update the tests before we drop tags entirely. Reviewed By: xavierd Differential Revision: D18995058 fbshipit-source-id: 8c63710cd4ed567ea24e32724b8660f9006a61f1
2019-12-18 00:45:17 +03:00
cb9a9f314b8b 0 default
identify: add template support This is based on a patch proposed last year by Mathias De Maré[1], with a few changes. - Tags and bookmarks are now formatted lists, for more flexible queries. - The templater is populated whether or not [-nibtB] is specified. (Plain output is unchanged.) This seems more consistent with other templated commands. - The 'id' property is a string, instead of a list. - The parents of 'wdir()' have their own list of attributes. I left 'id' as a string because it seems very useful for generating version info. It's also a bit strange because the value and meaning changes depending on whether or not --debug is passed (short vs full hash), whether the revision is a merge or not (one hash or two, separated by a '+'), the working directory or not (node vs p1node), and local or not (remote defaults to tip, and never has '+'). The equivalent string built with {rev} seems much less useful, and I couldn't think of a reasonable name, so I left it out. The discussion seemed to be pointing towards having a list of nodes, with more than one entry for a merge. It seems simpler to give the nodes a name, and use {node} for the actual commit probed, especially now that there is a virtual node for 'wdir()'. Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes. I'm not sure if the plan is to fill in all of the context attributes in these items, or if these nested items should simply be made {p1node} and {p1rev}. I used ':' as the tag separator for consistency with {tags} in the log templater. Likewise, bookmarks are separated by a space for consistency with the corresponding log template. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
$ hg id -Tjson
[
{
"bookmarks": [],
identify: rename 'changed' keyword -> 'dirty' I meant to do this before sending the initial templater support, but forgot. I'm quite surprised that 'dirty' doesn't occur in more user facing contexts, but there are a few, like the help for blackbox. It also more obviously mirrors the '(clean)' state printed by the summary command. I also didn't like that it was just one letter off from {changes} in the {latesttags} sub-keywords, which has a totally different meaning.
2017-06-26 00:46:35 +03:00
"dirty": "",
identify: add template support This is based on a patch proposed last year by Mathias De Maré[1], with a few changes. - Tags and bookmarks are now formatted lists, for more flexible queries. - The templater is populated whether or not [-nibtB] is specified. (Plain output is unchanged.) This seems more consistent with other templated commands. - The 'id' property is a string, instead of a list. - The parents of 'wdir()' have their own list of attributes. I left 'id' as a string because it seems very useful for generating version info. It's also a bit strange because the value and meaning changes depending on whether or not --debug is passed (short vs full hash), whether the revision is a merge or not (one hash or two, separated by a '+'), the working directory or not (node vs p1node), and local or not (remote defaults to tip, and never has '+'). The equivalent string built with {rev} seems much less useful, and I couldn't think of a reasonable name, so I left it out. The discussion seemed to be pointing towards having a list of nodes, with more than one entry for a merge. It seems simpler to give the nodes a name, and use {node} for the actual commit probed, especially now that there is a virtual node for 'wdir()'. Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes. I'm not sure if the plan is to fill in all of the context attributes in these items, or if these nested items should simply be made {p1node} and {p1rev}. I used ':' as the tag separator for consistency with {tags} in the log templater. Likewise, bookmarks are separated by a space for consistency with the corresponding log template. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
"id": "cb9a9f314b8b",
"node": "ffffffffffffffffffffffffffffffffffffffff",
tags: remove tags feature Summary: We no longer user tags in any of our repositories, so let's delete all the code and remove some tech debt. Previously drawdag was our last remaining use of tags, but in a previous diff I switched that to use bookmarks. Reviewed By: quark-zju Differential Revision: D19042226 fbshipit-source-id: d7871c71c1026599aa70fdd806418347ea214a8a
2020-01-07 23:29:27 +03:00
"parents": [{"node": "cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b", "rev": 0}]
identify: add template support This is based on a patch proposed last year by Mathias De Maré[1], with a few changes. - Tags and bookmarks are now formatted lists, for more flexible queries. - The templater is populated whether or not [-nibtB] is specified. (Plain output is unchanged.) This seems more consistent with other templated commands. - The 'id' property is a string, instead of a list. - The parents of 'wdir()' have their own list of attributes. I left 'id' as a string because it seems very useful for generating version info. It's also a bit strange because the value and meaning changes depending on whether or not --debug is passed (short vs full hash), whether the revision is a merge or not (one hash or two, separated by a '+'), the working directory or not (node vs p1node), and local or not (remote defaults to tip, and never has '+'). The equivalent string built with {rev} seems much less useful, and I couldn't think of a reasonable name, so I left it out. The discussion seemed to be pointing towards having a list of nodes, with more than one entry for a merge. It seems simpler to give the nodes a name, and use {node} for the actual commit probed, especially now that there is a virtual node for 'wdir()'. Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes. I'm not sure if the plan is to fill in all of the context attributes in these items, or if these nested items should simply be made {p1node} and {p1rev}. I used ':' as the tag separator for consistency with {tags} in the log templater. Likewise, bookmarks are separated by a space for consistency with the corresponding log template. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
}
]
tests: unify test-identify
2010-08-12 14:49:58 +04:00
identify: provide changectx to templater
2017-06-26 03:37:16 +03:00
test template keywords and functions which require changectx:
$ hg id -T '{rev} {node|shortest}\n'
2147483647 ffff
$ hg id -T '{parents % "{rev} {node|shortest} {desc}\n"}'
0 cb9a a
tests: unify test-identify
2010-08-12 14:49:58 +04:00
with modifications
$ echo b > a
$ hg id -n -t -b -i
tags: remove tip tag Summary: In a future diff we'll be removing tags. The most prevalent tag is 'tip', which shows up in a ton of test output. Let's drop that tag first, so we can safely update the tests before we drop tags entirely. Reviewed By: xavierd Differential Revision: D18995058 fbshipit-source-id: 8c63710cd4ed567ea24e32724b8660f9006a61f1
2019-12-18 00:45:17 +03:00
cb9a9f314b8b+ 0+ default
identify: add template support This is based on a patch proposed last year by Mathias De Maré[1], with a few changes. - Tags and bookmarks are now formatted lists, for more flexible queries. - The templater is populated whether or not [-nibtB] is specified. (Plain output is unchanged.) This seems more consistent with other templated commands. - The 'id' property is a string, instead of a list. - The parents of 'wdir()' have their own list of attributes. I left 'id' as a string because it seems very useful for generating version info. It's also a bit strange because the value and meaning changes depending on whether or not --debug is passed (short vs full hash), whether the revision is a merge or not (one hash or two, separated by a '+'), the working directory or not (node vs p1node), and local or not (remote defaults to tip, and never has '+'). The equivalent string built with {rev} seems much less useful, and I couldn't think of a reasonable name, so I left it out. The discussion seemed to be pointing towards having a list of nodes, with more than one entry for a merge. It seems simpler to give the nodes a name, and use {node} for the actual commit probed, especially now that there is a virtual node for 'wdir()'. Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes. I'm not sure if the plan is to fill in all of the context attributes in these items, or if these nested items should simply be made {p1node} and {p1rev}. I used ':' as the tag separator for consistency with {tags} in the log templater. Likewise, bookmarks are separated by a space for consistency with the corresponding log template. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
$ hg id -Tjson
[
{
"bookmarks": [],
identify: rename 'changed' keyword -> 'dirty' I meant to do this before sending the initial templater support, but forgot. I'm quite surprised that 'dirty' doesn't occur in more user facing contexts, but there are a few, like the help for blackbox. It also more obviously mirrors the '(clean)' state printed by the summary command. I also didn't like that it was just one letter off from {changes} in the {latesttags} sub-keywords, which has a totally different meaning.
2017-06-26 00:46:35 +03:00
"dirty": "+",
identify: add template support This is based on a patch proposed last year by Mathias De Maré[1], with a few changes. - Tags and bookmarks are now formatted lists, for more flexible queries. - The templater is populated whether or not [-nibtB] is specified. (Plain output is unchanged.) This seems more consistent with other templated commands. - The 'id' property is a string, instead of a list. - The parents of 'wdir()' have their own list of attributes. I left 'id' as a string because it seems very useful for generating version info. It's also a bit strange because the value and meaning changes depending on whether or not --debug is passed (short vs full hash), whether the revision is a merge or not (one hash or two, separated by a '+'), the working directory or not (node vs p1node), and local or not (remote defaults to tip, and never has '+'). The equivalent string built with {rev} seems much less useful, and I couldn't think of a reasonable name, so I left it out. The discussion seemed to be pointing towards having a list of nodes, with more than one entry for a merge. It seems simpler to give the nodes a name, and use {node} for the actual commit probed, especially now that there is a virtual node for 'wdir()'. Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes. I'm not sure if the plan is to fill in all of the context attributes in these items, or if these nested items should simply be made {p1node} and {p1rev}. I used ':' as the tag separator for consistency with {tags} in the log templater. Likewise, bookmarks are separated by a space for consistency with the corresponding log template. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
"id": "cb9a9f314b8b+",
"node": "ffffffffffffffffffffffffffffffffffffffff",
tags: remove tags feature Summary: We no longer user tags in any of our repositories, so let's delete all the code and remove some tech debt. Previously drawdag was our last remaining use of tags, but in a previous diff I switched that to use bookmarks. Reviewed By: quark-zju Differential Revision: D19042226 fbshipit-source-id: d7871c71c1026599aa70fdd806418347ea214a8a
2020-01-07 23:29:27 +03:00
"parents": [{"node": "cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b", "rev": 0}]
identify: add template support This is based on a patch proposed last year by Mathias De Maré[1], with a few changes. - Tags and bookmarks are now formatted lists, for more flexible queries. - The templater is populated whether or not [-nibtB] is specified. (Plain output is unchanged.) This seems more consistent with other templated commands. - The 'id' property is a string, instead of a list. - The parents of 'wdir()' have their own list of attributes. I left 'id' as a string because it seems very useful for generating version info. It's also a bit strange because the value and meaning changes depending on whether or not --debug is passed (short vs full hash), whether the revision is a merge or not (one hash or two, separated by a '+'), the working directory or not (node vs p1node), and local or not (remote defaults to tip, and never has '+'). The equivalent string built with {rev} seems much less useful, and I couldn't think of a reasonable name, so I left it out. The discussion seemed to be pointing towards having a list of nodes, with more than one entry for a merge. It seems simpler to give the nodes a name, and use {node} for the actual commit probed, especially now that there is a virtual node for 'wdir()'. Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes. I'm not sure if the plan is to fill in all of the context attributes in these items, or if these nested items should simply be made {p1node} and {p1rev}. I used ':' as the tag separator for consistency with {tags} in the log templater. Likewise, bookmarks are separated by a space for consistency with the corresponding log template. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
}
]
tests: unify test-identify
2010-08-12 14:49:58 +04:00
other local repo
$ cd ..
$ hg -R test id
tags: remove tip tag Summary: In a future diff we'll be removing tags. The most prevalent tag is 'tip', which shows up in a ton of test output. Let's drop that tag first, so we can safely update the tests before we drop tags entirely. Reviewed By: xavierd Differential Revision: D18995058 fbshipit-source-id: 8c63710cd4ed567ea24e32724b8660f9006a61f1
2019-12-18 00:45:17 +03:00
cb9a9f314b8b+
tests: convert some 'hghave no-outer-repo' to #if In some places we instead use 'hg init' to create a well-known outer repo without any special extensions or other config settings.
2012-06-21 01:41:21 +04:00
#if no-outer-repo
tests: unify test-identify
2010-08-12 14:49:58 +04:00
$ hg id test
cb9a9f314b8b+ tip
tests: convert some 'hghave no-outer-repo' to #if In some places we instead use 'hg init' to create a well-known outer repo without any special extensions or other config settings.
2012-06-21 01:41:21 +04:00
#endif
tests: unify test-identify
2010-08-12 14:49:58 +04:00
with remote http repo
$ cd test
serve: assign hg serve ports dynamically in tests Summary: Previously `hg server` uses `HGPORT` that might be in use. This patch uses `-p 0 --port-file ...` so `hg server` always gets assigned a free port. The change was first made by the following Ruby script: ``` re = /^ \$ hg serve(.*) -p \$(HGPORT[12]?) (.*[^\\])$\n \$/ Dir['*.t'].each do |path| old = File.read(path) new = old.lines.map do |l| next l if l[/\(glob\)/] or not l['$HGPORT'] or l[/^ [$>]/] "#{l.chomp} (glob)\n" end.join.gsub re, <<-'EOS'.chomp $ hg serve\1 -p 0 --port-file $TESTTMP/.port \3 $ \2=`cat $TESTTMP/.port` $ EOS File.write(path, new) if old != new end ``` Then there are some manual changes: run-tests.py: It now treats `$HGPORT` in output as glob pattern `*`, since it does not know the assigned value in tests. test-bookmarks-pushpull.t, test-https.t: Some `hg pull`s were changed to use explicit paths instead of relying on `.hgrc` since the test restarts the server and `.hg/hgrc` having an outdated URL. test-schemes.t: The test writes `$HGPORT` to `.hgrc` before assigning it. Changed the order so the correct `$HGPORT` is written. test-patchbomb-tls.t: Changed `(?) (glob)` to `(glob) (?)`. Reviewed By: DurhamG Differential Revision: D6925398 fbshipit-source-id: d5c10476f43ce23f9e99618807580cf8ba92595c
2018-02-08 02:18:29 +03:00
$ hg serve -p 0 --port-file $TESTTMP/.port -d --pid-file=hg.pid
$ HGPORT1=`cat $TESTTMP/.port`
tests: unify test-identify
2010-08-12 14:49:58 +04:00
$ cat hg.pid >> $DAEMON_PIDS
$ hg id http://localhost:$HGPORT1/
cb9a9f314b8b
id: add bookmarks to id Since bookmarks are no longer merged with repo.tags() as of 8e2d23f4bd25, they don't show up in `hg id` as they used to. This adds them back into the summary that `hg id` prints, and adds a -B/--bookmarks flag alongside the -t/--tags and -b/--branch options. Note this introduces a slight backwards-incompatibility: the summary printed by `hg id` now separates bookmarks from tags with a space, as seen below, instead of running it into the tags list. Default summary output: $ hg id db815d6d32e6 tip/tag1 bm1/bm2 Output with --bookmarks: $ hg id --bookmarks bm1 bm2 See also 5672c9e8202d which adds bookmarks back into `hg summary`.
2011-02-19 02:09:08 +03:00
remote with rev number?
$ hg id -n http://localhost:$HGPORT1/
tags: remove tags feature Summary: We no longer user tags in any of our repositories, so let's delete all the code and remove some tech debt. Previously drawdag was our last remaining use of tags, but in a previous diff I switched that to use bookmarks. Reviewed By: quark-zju Differential Revision: D19042226 fbshipit-source-id: d7871c71c1026599aa70fdd806418347ea214a8a
2020-01-07 23:29:27 +03:00
abort: can't query remote revision number or branch
id: add bookmarks to id Since bookmarks are no longer merged with repo.tags() as of 8e2d23f4bd25, they don't show up in `hg id` as they used to. This adds them back into the summary that `hg id` prints, and adds a -B/--bookmarks flag alongside the -t/--tags and -b/--branch options. Note this introduces a slight backwards-incompatibility: the summary printed by `hg id` now separates bookmarks from tags with a space, as seen below, instead of running it into the tags list. Default summary output: $ hg id db815d6d32e6 tip/tag1 bm1/bm2 Output with --bookmarks: $ hg id --bookmarks bm1 bm2 See also 5672c9e8202d which adds bookmarks back into `hg summary`.
2011-02-19 02:09:08 +03:00
[255]
remote with branch?
$ hg id -b http://localhost:$HGPORT1/
tags: remove tags feature Summary: We no longer user tags in any of our repositories, so let's delete all the code and remove some tech debt. Previously drawdag was our last remaining use of tags, but in a previous diff I switched that to use bookmarks. Reviewed By: quark-zju Differential Revision: D19042226 fbshipit-source-id: d7871c71c1026599aa70fdd806418347ea214a8a
2020-01-07 23:29:27 +03:00
abort: can't query remote revision number or branch
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[255]
introduce new RequirementError (issue2649) This improves the misleading error message $ hg identify abort: there is no Mercurial repository here (.hg not found)! to the more explicit $ hg identify abort: requirement 'fake' not supported! for all commands in commands.optionalrepo, which includes the identify and serve commands in particular. This is for the case when a new entry in .hg/requires will be defined in a future Mercurial release.
2011-02-18 22:25:25 +03:00
tests: add tests for bookmarks support in hg identify
2011-03-13 16:35:17 +03:00
test bookmark support
$ hg bookmark Y
$ hg bookmark Z
$ hg bookmarks
Y 0:cb9a9f314b8b
* Z 0:cb9a9f314b8b
$ hg id
tags: remove tip tag Summary: In a future diff we'll be removing tags. The most prevalent tag is 'tip', which shows up in a ton of test output. Let's drop that tag first, so we can safely update the tests before we drop tags entirely. Reviewed By: xavierd Differential Revision: D18995058 fbshipit-source-id: 8c63710cd4ed567ea24e32724b8660f9006a61f1
2019-12-18 00:45:17 +03:00
cb9a9f314b8b+ Y/Z
tests: add tests for bookmarks support in hg identify
2011-03-13 16:35:17 +03:00
$ hg id --bookmarks
Y Z
test remote identify with bookmarks
$ hg id http://localhost:$HGPORT1/
cb9a9f314b8b Y/Z
$ hg id --bookmarks http://localhost:$HGPORT1/
Y Z
$ hg id -r . http://localhost:$HGPORT1/
cb9a9f314b8b Y/Z
$ hg id --bookmarks -r . http://localhost:$HGPORT1/
Y Z
httppeer: reintroduce _abort that accidentally was removed in fc14a1cf743e Including the missing test coverage that would have caught it.
2014-04-24 01:29:55 +04:00
test invalid lookup
$ hg id -r noNoNO http://localhost:$HGPORT1/
abort: unknown revision 'noNoNO'!
[255]
introduce new RequirementError (issue2649) This improves the misleading error message $ hg identify abort: there is no Mercurial repository here (.hg not found)! to the more explicit $ hg identify abort: requirement 'fake' not supported! for all commands in commands.optionalrepo, which includes the identify and serve commands in particular. This is for the case when a new entry in .hg/requires will be defined in a future Mercurial release.
2011-02-18 22:25:25 +03:00
Make sure we do not obscure unknown requires file entries (issue2649)
$ echo fake >> .hg/requires
$ hg id
repo: rephrase the "missing requirement" error message Unknown requirements will now be reported as: abort: repository requires features unknown to this Mercurial: largefiles! (see http://mercurial.selenic.com/wiki/MissingRequirement for more information) Some features of this phrasing: * avoid double ':' in abort message * make it more clear who requires and knows what * don't quote the requirement names - it is not something the user entered or need the exact spelling of ... and it is "identifiers" that are unambiguous anyway * remove double hint by removing "(upgrade Mercurial)" comment * don't mention upgrading Mercurial without mentioning enabling the feature - instead, just refer to wiki page for both * don't just talk about "details", talk about "more information"
2014-03-19 03:18:30 +04:00
abort: repository requires features unknown to this Mercurial: fake!
urls: bulk-change primary website URLs
2015-09-30 23:43:49 +03:00
(see https://mercurial-scm.org/wiki/MissingRequirement for more information)
introduce new RequirementError (issue2649) This improves the misleading error message $ hg identify abort: there is no Mercurial repository here (.hg not found)! to the more explicit $ hg identify abort: requirement 'fake' not supported! for all commands in commands.optionalrepo, which includes the identify and serve commands in particular. This is for the case when a new entry in .hg/requires will be defined in a future Mercurial release.
2011-02-18 22:25:25 +03:00
[255]
$ cd ..
tests: convert some 'hghave no-outer-repo' to #if In some places we instead use 'hg init' to create a well-known outer repo without any special extensions or other config settings.
2012-06-21 01:41:21 +04:00
#if no-outer-repo
introduce new RequirementError (issue2649) This improves the misleading error message $ hg identify abort: there is no Mercurial repository here (.hg not found)! to the more explicit $ hg identify abort: requirement 'fake' not supported! for all commands in commands.optionalrepo, which includes the identify and serve commands in particular. This is for the case when a new entry in .hg/requires will be defined in a future Mercurial release.
2011-02-18 22:25:25 +03:00
$ hg id test
repo: rephrase the "missing requirement" error message Unknown requirements will now be reported as: abort: repository requires features unknown to this Mercurial: largefiles! (see http://mercurial.selenic.com/wiki/MissingRequirement for more information) Some features of this phrasing: * avoid double ':' in abort message * make it more clear who requires and knows what * don't quote the requirement names - it is not something the user entered or need the exact spelling of ... and it is "identifiers" that are unambiguous anyway * remove double hint by removing "(upgrade Mercurial)" comment * don't mention upgrading Mercurial without mentioning enabling the feature - instead, just refer to wiki page for both * don't just talk about "details", talk about "more information"
2014-03-19 03:18:30 +04:00
abort: repository requires features unknown to this Mercurial: fake!
urls: bulk-change primary website URLs
2015-09-30 23:43:49 +03:00
(see https://mercurial-scm.org/wiki/MissingRequirement for more information)
introduce new RequirementError (issue2649) This improves the misleading error message $ hg identify abort: there is no Mercurial repository here (.hg not found)! to the more explicit $ hg identify abort: requirement 'fake' not supported! for all commands in commands.optionalrepo, which includes the identify and serve commands in particular. This is for the case when a new entry in .hg/requires will be defined in a future Mercurial release.
2011-02-18 22:25:25 +03:00
[255]
tests: convert some 'hghave no-outer-repo' to #if In some places we instead use 'hg init' to create a well-known outer repo without any special extensions or other config settings.
2012-06-21 01:41:21 +04:00
#endif
Reference in New Issue Copy Permalink