- Use '/' key to quickly access this field.
- Enter a name of repository, or repository group for quick search.
- Prefix query to allow special search:
user:admin, to search for usernames, always global
user_group:devops, to search for user groups, always global
pr:303, to search for pull request number, title, or description, always global
commit:efced4, to search for commits, scoped to repositories or groups
file:models.py, to search for file paths, scoped to repositories or groups
For advanced full text search visit: repository search
bisect: avoid adding irrelevant revisions to bisect state...
bisect: avoid adding irrelevant revisions to bisect state
When adding new revisions to the bisect state, it only makes sense to add
information about revisions that are under consideration (i.e., those that are
topologically between the known good and bad revisions). However, if the user
passes in a revset (e.g., '!merge()' to exclude merge commits), hg will resolve
the revset first and add all matching revisions to the bisect state (which in
this case would likely be the majority of revisions in the repo). To avoid this,
revisions should only be added to the bisect state if they are between the good
and bad revisions (and therefore relevant to the bisection).
--
Here are the results of some performance tests using the `mozilla-central` repo
(since it is one of the largest freely-available hg repositories in the wild).
These tests compare the performance of a locally-built `hg` before and after
application of this series. Note that `--noupdate` is passed to avoid including
update time (which should not vary across cases).
Setup (run between each test):
$ hg bisect --reset
$ hg bisect --noupdate --bad 56c3ad4bde5c70714b784ccf15d099e0df0f5bde
$ hg bisect --noupdate --good 57426696adaf08298af3027fa77486fee0633b13
Test using a revset that returns a very large number of revisions:
$ time hg bisect --noupdate --skip '!merge()' > /dev/null
Before:
real 0m9.398s
user 0m9.233s
sys 0m0.120s
After:
real 0m1.513s
user 0m1.425s
sys 0m0.052s
Test using a revset that is expensive to compute:
$ time hg bisect --noupdate --skip 'desc("Bug")' > /dev/null
Before:
real 0m49.853s
user 0m49.580s
sys 0m0.243s
After:
real 0m4.120s
user 0m4.036s
sys 0m0.048s
"string":"{\"result\":[{\"id\":\"6876\",\"phid\":\"PHID-DREV-looitrxgt3omaau7a7qk\",\"title\":\"phabricator: support automatically obsoleting old revisions of pulled commits\",\"uri\":\"https:\\/\\/phab.mercurial-scm.org\\/D6876\",\"dateCreated\":\"1569388644\",\"dateModified\":\"1579887103\",\"authorPHID\":\"PHID-USER-tzhaient733lwrlbcag5\",\"status\":\"1\",\"statusName\":\"Needs Revision\",\"properties\":{\"draft.broadcast\":true,\"lines.added\":68,\"lines.removed\":1},\"branch\":null,\"summary\":\"This is basically an import of the `pullcreatemarkers` extension[1] from the FB\\nrepo, with minor adjustments to `getmatchingdiff()` to work with modern hg.\\nSince this is very phabricator specific, it makes more sense to me to bundle it\\ninto the existing extension. It wasn't very obvious from the old name what\\nfunctionality was provided, and it may make sense to do this in other scenarios\\nbesides `hg pull`.\\n\\nThere are two use cases that I can see- first, ensuring that old revisions are\\ncleaned up for a contributor (I seem to recall something I submitted recently\\nneeded to be explicitly pruned, though most submissions do clean up\\nautomatically). Second, any `hg phabread | hg import -` would otherwise need to\\nbe manually cleaned up. The latter is annoying enough that I tend not to grab\\nthe code and try it when reviewing.\\n\\nIt is currently guarded by a config option (off by default), because @marmoute\\nexpressed concerns about duplicate marker creation if the pushing reviewer also\\ncreates a marker. I don't think that's possible here, since the obsolete\\nrevisions are explicitly excluded. But maybe there are other reasons someone\\nwouldn't want older revisions obsoleted. The config name reflects the fact that\\nI'm not sure if other things like import should get this too.\\n\\nI suspect that we could wrap a function deeper in the pull sequence to improve\\nboth the code and the UX. For example, when pulling an obsolete marker, it can\\nprint out a warning that the working directory parent is obsolete, but that\\ndoesn't happen here. (It won't happen with this test. It *should* without the\\n`--bypass` option, but doesn't.) It should also be possible to not have to\\nquery the range of new revisions, and maybe it can be added to the existing\\ntransaction.\\n\\n[1] https:\\/\\/bitbucket.org\\/facebook\\/hg-experimental\\/src\\/default\\/hgext3rd\\/pullcreatemarkers.py\",\"testPlan\":\"\",\"lineCount\":\"69\",\"activeDiffPHID\":\"PHID-DIFF-jdpqpzciqcooaxf2kojh\",\"diffs\":[\"16604\"],\"commits\":[],\"reviewers\":{\"PHID-PROJ-3dvcxzznrjru2xmmses3\":\"PHID-PROJ-3dvcxzznrjru2xmmses3\",\"PHID-USER-cah4b6i3kszy6debh3bl\":\"PHID-USER-cah4b6i3kszy6debh3bl\"},\"ccs\":[\"PHID-USER-34jnztnonbr4lhwuybwl\",\"PHID-USER-e66t6wbudjtigdnqbl3e\",\"PHID-USER-5iy6mkoveguhm2zthvww\",\"PHID-USER-q42dn7cc3donqriafhjx\",\"PHID-USER-vflsibccj4unqydwfvne\"],\"hashes\":[],\"auxiliary\":{\"phabricator:projects\":[],\"phabricator:depends-on\":[\"PHID-DREV-2dbanvk64h5wguhxta2o\"]},\"repositoryPHID\":\"PHID-REPO-bvunnehri4u2isyr7bc3\",\"sourcePath\":null}],\"error_code\":null,\"error_info\":null}"