cli: evolog: show associated operation for recent commits (PoC)

[yuja]

This patch isn't intended for merging. The idea is that we'll record operation ids where the commits were introduced in index, and jj evolog will use this information to extract the operation object. Since commits should be added only once to the index, this should be compatible with the current (append-only, immutable) index model. (If we were to index newly visible/hidden commits per operation, we would need separate index structure.)

I think the predecessors can be stored in the operation object, but I don't have strong feeling about that. Even if we decide to remove the predecessors information at all, we can still benefit from the "commit_id: operation_id" index. jj evolog would first look up the originating operation, then compute diffs of visible commits to deduce the predecessor commit. In this implementation, visibility changes (e.g. abandoned) wouldn't be included (unlike the operation log.)

#963

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

[martinvonz]

The idea is that we'll record operation
ids where the commits were introduced in index, and jj evolog will use this
information to extract the operation object.

I'm not sure how we're going to make this work at Google. The index there is separate from operation log. You can create a commit without creating any operation and it will still be in the index. So it's undefined which operation introduced a given commit.

Thinking about what information we need for the feature, and in particular assuming we don't have predecessor pointers, we need to first find the operations that modified a given change (i.e. added or removed commits with the given change id). That seems like something that would fit into an "opset". Maybe we'd want a function on OpStore trait for evaluating an opset. It can still be expensive to load the repo at each operation to find the relevant commit ids. I don't know if that means that we should have something more specific for this use case than an opset evaluator.

[yuja]

I'm not sure how we're going to make this work at Google. The index there is separate from operation log. You can create a commit without creating any operation and it will still be in the index. So it's undefined which operation introduced a given commit.

Thinking about what information we need for the feature, and in particular assuming we don't have predecessor pointers, we need to first find the operations that modified a given change (i.e. added or removed commits with the given change id). That seems like something that would fit into an "opset". Maybe we'd want a function on OpStore trait for evaluating an opset. It can still be expensive to load the repo at each operation to find the relevant commit ids. I don't know if that means that we should have something more specific for this use case than an opset evaluator.

Something like index.resolve(op_store, commit_id|change_id|op_set) -> graph_iter|commit_operation_pair or op_store.resolve(index, ..) -> .. seems good if that works for Google.

FWIW, I think evolution log should be keyed by commit_id, not by change_id. change_id-based history might work if the forge can guarantee that there are no duplicated changes, but that's no the case for opensource Git repos.

[PhilipMetzger]

FWIW, I think evolution log should be keyed by commit_id, not by change_id. change_id-based history might work if the forge can guarantee that there are no duplicated changes, but that's no the case for opensource Git repos.

I pretty much think this should be backend-dependent since some them will probably align with their forges.

Thinking about what information we need for the feature, and in particular assuming we don't have predecessor pointers, we need to first find the operations that modified a given change (i.e. added or removed commits with the given change id). That seems like something that would fit into an "opset". Maybe we'd want a function on OpStore trait for evaluating an opset. It can still be expensive to load the repo at each operation to find the relevant commit ids. I don't know if that means that we should have something more specific for this use case than an opset evaluator.

SGTM

[yuja]

Superseded by #6628.