Conversation
cli/src/commands/redo.rs
Outdated
| let mut op_to_restore = match op_to_redo.parents().at_most_one().ok().flatten() { | ||
| let mut op_to_restore = match op_to_redo | ||
| .parents() | ||
| .collect::<Vec<_>>() |
There was a problem hiding this comment.
nit: Can we use try_collect() to simplify a bit?
There was a problem hiding this comment.
or make op.parents() collect into Vec<_>? Commit::parents() is implemented that way, and I don't have strong feeling that these parents() calls should be optimized.
There was a problem hiding this comment.
I pushed a version which makes op.parents() return OpStoreResult<Vec<Operation>>, but it does make some of the other call sites have to translate those back to Vec<OpStoreResult<Operation>>. I’m not sure I prefer that.
There was a problem hiding this comment.
I think we'll need to redesign DAG utility anyway for a better async support. The current callback-based sync API already has redundant .collect() because a borrowed iterator can't be returned, and async fn would increase complexity of borrowing further.
cli/src/commands/undo.rs
Outdated
| let mut op_to_restore = match op_to_undo.parents().at_most_one() { | ||
| let mut op_to_restore = match op_to_undo | ||
| .parents() | ||
| .collect::<Vec<_>>() |
bnjmnt4n
force-pushed
the
bnjmnt4n/push-vvzoxzoklzkp
branch
from
7dd541a to
84a317a
Compare
martinvonz
left a comment
martinvonz
left a comment
There was a problem hiding this comment.
Since this PR seems to update all callers of closest_common_node_ok() to want Result<Vec<T>, E> instead of Vec<Result<T, E>, perhaps we should update closest_common_node_ok() to work with that type.
| } else { | ||
| let op = resolve_op(&args.operation).await?; | ||
| let parent_ops: Vec<_> = op.parents().try_collect()?; | ||
| let parent_ops: Vec<_> = op.parents().await?; |
There was a problem hiding this comment.
nit: Can remove the type annotation. Same in many other places.
3 participants
Checklist
If applicable:
CHANGELOG.mdREADME.md,docs/,demos/)cli/src/config-schema.json)how it works, how it's organized), including any code drafted by an LLM.
an eye towards deleting anything that is irrelevant, clarifying anything
that is confusing, and adding details that are relevant. This includes,
for example, commit descriptions, PR descriptions, and code comments.