mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2024-12-28 23:55:54 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
jj/cli/testing/bench-revsets-git.txt

76 lines
1.5 KiB
Text
Raw Normal View History

cli: add a command for benchmarking many revsets This command is similar to Mercurial's revset benchmarking command. It lets you pass in a file containing revsets. I also included a file with some revsets to test on the git.git repo. I put it in `testing/`, which doesn't seem perfect. I'm happy to hear suggestions for better places, or we can move it later if we find a better place. Note that these tests don't clear caches between each run (or even between tests), so revsets that rely on filtering commit data that's not indexed appear faster than they typically are in reality.
2023-03-27 16:36:00 +00:00
# Revsets to pass to `jj bench revsets` on the Git
# Single tags
v1.0.0
v2.40.0
# Old history
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
::v1.0.0
cli: add a command for benchmarking many revsets This command is similar to Mercurial's revset benchmarking command. It lets you pass in a file containing revsets. I also included a file with some revsets to test on the git.git repo. I put it in `testing/`, which doesn't seem perfect. I'm happy to hear suggestions for better places, or we can move it later if we find a better place. Note that these tests don't clear caches between each run (or even between tests), so revsets that rely on filtering commit data that's not indexed appear faster than they typically are in reality.
2023-03-27 16:36:00 +00:00
..v1.0.0
# More history
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
::v2.40.0
cli: add a command for benchmarking many revsets This command is similar to Mercurial's revset benchmarking command. It lets you pass in a file containing revsets. I also included a file with some revsets to test on the git.git repo. I put it in `testing/`, which doesn't seem perfect. I'm happy to hear suggestions for better places, or we can move it later if we find a better place. Note that these tests don't clear caches between each run (or even between tests), so revsets that rely on filtering commit data that's not indexed appear faster than they typically are in reality.
2023-03-27 16:36:00 +00:00
..v2.40.0
# Only recent history
v2.39.0..v2.40.0
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
::v2.40.0 ~ ::v2.39.0
v2.39.0::v2.40.0
revset: add substitution rule for "::x & ~(::y-)" Suppose the generation value is usually small, it should be faster to do bounded range look up first 'y-', then walk ancestors with the unwanted set 'y-..x'.
2024-03-12 10:22:16 +00:00
# Mostly recent history
v2.40.0-..
revset: substitute '~(::x)' to 'x..' Suppose we have an alias 'immutable()' = '::immutable_heads()', user can express (visible) mutable set as '~immutable()'. 'immutable_heads()..' can terminate early, but a generic difference 'all() & ~immutable()' can't.
2024-03-12 09:51:02 +00:00
~(::v2.40.0)
cli: add a command for benchmarking many revsets This command is similar to Mercurial's revset benchmarking command. It lets you pass in a file containing revsets. I also included a file with some revsets to test on the git.git repo. I put it in `testing/`, which doesn't seem perfect. I'm happy to hear suggestions for better places, or we can move it later if we find a better place. Note that these tests don't clear caches between each run (or even between tests), so revsets that rely on filtering commit data that's not indexed appear faster than they typically are in reality.
2023-03-27 16:36:00 +00:00
# Tags and branches
tags()
branches()
revset: ad-hoc optimization for range queries containing unwanted wanted heads In my linux stable mirror, this makes the default log revset evaluation super fast. immutable_heads(), if configured properly, includes many historical branch heads which are also the visible heads. revsets/immutable_heads().. --------------------------- 0 12.27 117.1±0.77m 3 1.00 9.5±0.08m
2024-02-19 13:54:10 +00:00
# Local changes
(tags() | remote_branches())..
cli: add a command for benchmarking many revsets This command is similar to Mercurial's revset benchmarking command. It lets you pass in a file containing revsets. I also included a file with some revsets to test on the git.git repo. I put it in `testing/`, which doesn't seem perfect. I'm happy to hear suggestions for better places, or we can move it later if we find a better place. Note that these tests don't clear caches between each run (or even between tests), so revsets that rely on filtering commit data that's not indexed appear faster than they typically are in reality.
2023-03-27 16:36:00 +00:00
# Intersection of range with a small subset
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
tags() & ::v2.40.0
v2.39.0 & ::v2.40.0
cli: add a command for benchmarking many revsets This command is similar to Mercurial's revset benchmarking command. It lets you pass in a file containing revsets. I also included a file with some revsets to test on the git.git repo. I put it in `testing/`, which doesn't seem perfect. I'm happy to hear suggestions for better places, or we can move it later if we find a better place. Note that these tests don't clear caches between each run (or even between tests), so revsets that rely on filtering commit data that's not indexed appear faster than they typically are in reality.
2023-03-27 16:36:00 +00:00
# Author and committer
author(peff)
committer(gitster)
# Intersection and union of large subsets
author(peff) & committer(gitster)
author(peff) | committer(gitster)
revset: do not always evaluate filter node to InternalRevset This basically removes hidden 'all() &' from union/negation of filters. To achieve that, I have two options: 1. add separate evaluation path (like the one this commit introduced), or 2. wrap "all()" revset to override predicate as Box::new(|_| true) function. I took the former since it's less ad-hoc. We can add an explicit RevsetExpression node to branch between evaluate() and evaluate_predicate(), but I don't think it would simplify the implementation at this point. We might need such node if we want to resolve "all()" at resolve_symbols(). It might be even better to extract a subset of RevsetExpression enum, which only contains evaluatable nodes. The cost of 'all() &' isn't significant for most filters. '~merges()' is the exception. For jj repo, revsets/:v0.3.0 & (author(martinvonz) | committer(martinvonz)) -------------------------------------------------------------- base 1.06 11.2±0.04m new 1.00 10.5±0.05m revsets/~merges() ----------------- base 1.69 750.0±8.47µ new 1.00 444.1±3.50µ
2023-04-01 07:41:47 +00:00
# Intersection of filter with a small subset
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
::v1.0.0 & (author(peff) & committer(gitster))
::v1.0.0 & (author(peff) | committer(gitster))
cli: add a command for benchmarking many revsets This command is similar to Mercurial's revset benchmarking command. It lets you pass in a file containing revsets. I also included a file with some revsets to test on the git.git repo. I put it in `testing/`, which doesn't seem perfect. I'm happy to hear suggestions for better places, or we can move it later if we find a better place. Note that these tests don't clear caches between each run (or even between tests), so revsets that rely on filtering commit data that's not indexed appear faster than they typically are in reality.
2023-03-27 16:36:00 +00:00
# Roots and heads of small subsets
roots(tags())
heads(tags())
# Roots and heads of large subsets
roots(author(peff))
heads(author(peff))
# Roots and heads of range
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
roots(::v2.40.0)
heads(::v2.40.0)
index: merge overlapped generation ranges to be enqueued Before, the number of the generations to track would increase at each merge point. This was really bad for queries like ':@--' in merge-heavy history, but I didn't notice the problem because ancestors query is lazy and the default log template is slow. Since I'm going to reuse RevWalk for 'roots++:' queries, which can't be lazy, I need to fix this problem first. As we don't have a revset expression to specify exact generation range, gen.end is initialized to either 1 or close to u32::MAX. So, this change means long-lived generation ranges will eventually be merged into one.
2023-04-25 12:01:23 +00:00
# Parents and ancestors of old commit
v1.0.0-
v1.0.0---
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
::v1.0.0---
revset: do not scan ancestors more than once to evaluate nested children set
2023-04-21 09:12:10 +00:00
# Children and descendants of old commit
v1.0.0+
v1.0.0+++
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
v1.0.0+++::
index: merge overlapped generation ranges to be enqueued Before, the number of the generations to track would increase at each merge point. This was really bad for queries like ':@--' in merge-heavy history, but I didn't notice the problem because ancestors query is lazy and the default log template is slow. Since I'm going to reuse RevWalk for 'roots++:' queries, which can't be lazy, I need to fix this problem first. As we don't have a revset expression to specify exact generation range, gen.end is initialized to either 1 or close to u32::MAX. So, this change means long-lived generation ranges will eventually be merged into one.
2023-04-25 12:01:23 +00:00
# Parents and ancestors of recent commit
v2.40.0-
v2.40.0---
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
::v2.40.0---
revset: do not scan ancestors more than once to evaluate nested children set
2023-04-21 09:12:10 +00:00
# Children and descendants of recent commit
v2.40.0+
v2.40.0+++
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
v2.40.0+++::
index: merge overlapped generation ranges to be enqueued Before, the number of the generations to track would increase at each merge point. This was really bad for queries like ':@--' in merge-heavy history, but I didn't notice the problem because ancestors query is lazy and the default log template is slow. Since I'm going to reuse RevWalk for 'roots++:' queries, which can't be lazy, I need to fix this problem first. As we don't have a revset expression to specify exact generation range, gen.end is initialized to either 1 or close to u32::MAX. So, this change means long-lived generation ranges will eventually be merged into one.
2023-04-25 12:01:23 +00:00
# Parents and ancestors of small subset
cli: add a command for benchmarking many revsets This command is similar to Mercurial's revset benchmarking command. It lets you pass in a file containing revsets. I also included a file with some revsets to test on the git.git repo. I put it in `testing/`, which doesn't seem perfect. I'm happy to hear suggestions for better places, or we can move it later if we find a better place. Note that these tests don't clear caches between each run (or even between tests), so revsets that rely on filtering commit data that's not indexed appear faster than they typically are in reality.
2023-03-27 16:36:00 +00:00
tags()-
index: merge overlapped generation ranges to be enqueued Before, the number of the generations to track would increase at each merge point. This was really bad for queries like ':@--' in merge-heavy history, but I didn't notice the problem because ancestors query is lazy and the default log template is slow. Since I'm going to reuse RevWalk for 'roots++:' queries, which can't be lazy, I need to fix this problem first. As we don't have a revset expression to specify exact generation range, gen.end is initialized to either 1 or close to u32::MAX. So, this change means long-lived generation ranges will eventually be merged into one.
2023-04-25 12:01:23 +00:00
tags()---
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
::tags()---
revset: do not scan ancestors more than once to evaluate nested children set
2023-04-21 09:12:10 +00:00
# Children and descendants of small subset
cli: add a command for benchmarking many revsets This command is similar to Mercurial's revset benchmarking command. It lets you pass in a file containing revsets. I also included a file with some revsets to test on the git.git repo. I put it in `testing/`, which doesn't seem perfect. I'm happy to hear suggestions for better places, or we can move it later if we find a better place. Note that these tests don't clear caches between each run (or even between tests), so revsets that rely on filtering commit data that's not indexed appear faster than they typically are in reality.
2023-03-27 16:36:00 +00:00
tags()+
revset: do not scan ancestors more than once to evaluate nested children set
2023-04-21 09:12:10 +00:00
tags()+++
revsets: allow `::` as synonym for `:` The `--allow-large-revsets` flag we have on `jj rebase` and `jj new` allows the user to do e.g. `jj rebase --allow-large-revsets -b main.. -d main` to rebase all commits that are not in main onto main. The reason we don't allow these revsets to resolve to multiple commits by default is that we think users might specify multiple commits by mistake. That's probably not much of a problem with `jj rebase -b` (maybe we should always allow that to resolve to multiple commits), but the user might want to know if `jj rebase -d @-` resolves to multiple commits. One problem with having a flag to allow multiple commits is that it needs to be added to every command where we want to allow multiple commits but default to one. Also, it should probably apply to each revset argument those commands take. For example, even if the user meant `-b main..` to resolve to multiple commits, they might not have meant `-d main` to resolve to multiple commits (which it will in case of a conflicted branch), so we might want separate `--allow-large-revsets-in-destination` and `--allow-large-revsets-in-source`, which gets quite cumbersome. It seems better to have some syntax in the individual revsets for saying that multiple commits are allowed. One proposal I had was to use a `multiple()` revset function which would have no effect in general but would be used as a marker if used at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some discussion on the PR adding that function (#1911), it seems that the consensus is to instead use a prefix like `many:` or `all:`. That avoids the problem with having a function that has no effect unless it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have no effect). Since we already have the `:` operator for DAG ranges, we need to change it to make room for `many:`/`all:` syntax. This commit starts that by allowing both `:` and `::`. I have tried to update the documentation in this commit to either mention both forms, or just the new and preferred `::` form. However, it's useless to search for `:` in Rust code, so I'm sure I've missed many instances. We'll have to address those as we notice them. I'll let most tests use `:` until we deprecate it or delete it.
2023-07-27 23:27:44 +00:00
tags()+++::
revset: do not always evaluate filter node to InternalRevset This basically removes hidden 'all() &' from union/negation of filters. To achieve that, I have two options: 1. add separate evaluation path (like the one this commit introduced), or 2. wrap "all()" revset to override predicate as Box::new(|_| true) function. I took the former since it's less ad-hoc. We can add an explicit RevsetExpression node to branch between evaluate() and evaluate_predicate(), but I don't think it would simplify the implementation at this point. We might need such node if we want to resolve "all()" at resolve_symbols(). It might be even better to extract a subset of RevsetExpression enum, which only contains evaluatable nodes. The cost of 'all() &' isn't significant for most filters. '~merges()' is the exception. For jj repo, revsets/:v0.3.0 & (author(martinvonz) | committer(martinvonz)) -------------------------------------------------------------- base 1.06 11.2±0.04m new 1.00 10.5±0.05m revsets/~merges() ----------------- base 1.69 750.0±8.47µ new 1.00 444.1±3.50µ
2023-04-01 07:41:47 +00:00
# Filter that doesn't read commit object
merges()
~merges()
revset: add a revset function for finding commits with conflicts This adds `conflict()` revset that selects commits with conflicts. We may want to extend it later to consider only conflicts at certain paths.
2023-04-05 03:05:51 +00:00
# These are unbearably slow, so only filter within small set
cli: add a command for benchmarking many revsets This command is similar to Mercurial's revset benchmarking command. It lets you pass in a file containing revsets. I also included a file with some revsets to test on the git.git repo. I put it in `testing/`, which doesn't seem perfect. I'm happy to hear suggestions for better places, or we can move it later if we find a better place. Note that these tests don't clear caches between each run (or even between tests), so revsets that rely on filtering commit data that's not indexed appear faster than they typically are in reality.
2023-03-27 16:36:00 +00:00
file(Makefile) & v1.0.0..v1.2.0
revset: make empty()/file(".") not load root tree for liner history TreeDiffIterator wouldn't load identical subtrees, but it's up to caller to optimize out the root tree loading.
2023-04-05 07:19:32 +00:00
empty() & v1.0.0..v1.2.0
revset: add a revset function for finding commits with conflicts This adds `conflict()` revset that selects commits with conflicts. We may want to extend it later to consider only conflicts at certain paths.
2023-04-05 03:05:51 +00:00
conflict() & v1.0.0..v1.2.0
Reference in a new issue Copy permalink