cli: op log: add --bookmark option to filter operations by bookmark

[bnjmnt4n]

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes

[bnjmnt4n]

I've wrote a preliminary version of this feature, which allows filtering op log entries by bookmark. Unfortunately it's not very performant, because it requires doing a toposort of the whole op log before filtering out irrelevant entries. In contrast, the plain (unfiltered) op log has a lazy iterator to go through linear portions of the graph, which I think would be large portions of the graph for most.

I'm not sure if there is a way to correctly construct the graph with elided revisions in a lazy manner? My understanding (do correct me if I'm wrong) is that the regular jj log is able to construct the graph lazily due to it already knowing the items in the "input set", as well as the use of the index and generation count.

I'm also not that familiar with graphs, so perhaps there are better algorithms for this?

[yuja]

Maybe we can apply the same workaround as the lazy iterator? It just splits the graph into linear and non-linear parts, and processes non-linear part eagerly.

FWIW, we'll need opset language at some point, but adding --bookmark flag seems okay until then.

[bnjmnt4n]

Maybe we can apply the same workaround as the lazy iterator? It just splits the graph into linear and non-linear parts, and processes non-linear part eagerly.

I was thinking the same, but I'll probably need a bit more time to go through the code to understand and adapt the algorithm.

FWIW, we'll need opset language at some point, but adding --bookmark flag seems okay until then.

I also wanted to add the ability to filter by change ID, so perhaps the opset language might come in sooner rather than later?

[yuja]

I was thinking the same, but I'll probably need a bit more time to go through the code to understand and adapt the algorithm.

Since op log is usually linear, it's probably okay to not implement skip_transitive_edges. It might help reuse the existing code by somehow pre-processing the input op -> parents chains.

I also wanted to add the ability to filter by change ID, so perhaps the opset language might come in sooner rather than later?

It might be also okay to add minimal opset parser (something like strip_prefix("bookmarks(") ...)

[bnjmnt4n]

Is the eventual intention to get something like jj op log --op "@ | id1..id2 working?

Since op log is usually linear, it's probably okay to not implement skip_transitive_edges. It might help reuse the existing code by somehow pre-processing the input op -> parents chains.

This is referring to the code in RevsetGraphWalk right? Without an op store index, I don't think it's possible to easily reuse that code because it depends on the input being already sorted?

Unless we intend to create an operation store index, I was thinking we could attempt to resolve any resolvable ops in the opset first (apart from bookmarks(x) for now), then iterate through the op graph and filter ops if they are not in the input set and if the bookmarks predicate doesn't apply. I think I might be able to convert the filtering to a lazy method with some time.

[yuja]

Is the eventual intention to get something like jj op log --op "@ | id1..id2 working?

Yes, it's nice if op log supports arbitrary range/filter query.

Since op log is usually linear, it's probably okay to not implement skip_transitive_edges. It might help reuse the existing code by somehow pre-processing the input op -> parents chains.

This is referring to the code in RevsetGraphWalk right? Without an op store index, I don't think it's possible to easily reuse that code because it depends on the input being already sorted?

I meant dag_walk::topo_order_reverse_lazy_ok() might be reusable by filtering the inputs. To achieve skip_transitive_edges = true, the graph iterator would have to know whether the edge is direct or not, but that wouldn't be needed for op log where the graph is usually linear so it's rare that filtered graph had redundant edges.

Unless we intend to create an operation store index, I was thinking we could attempt to resolve any resolvable ops in the opset first (apart from bookmarks(x) for now), then iterate through the op graph and filter ops if they are not in the input set and if the bookmarks predicate doesn't apply. I think I might be able to convert the filtering to a lazy method with some time.

I think most part of "opset" expression will be transformed to Fn(&Opration) -> bool function. Some common range expression (like ::<head> & ..) might be extracted to optimize range query.