FR: revset functions for traversing the obslog

[eopb]

Problem

Revsets are very cool. They provide a way to select a set of changes, without having to run jj log and manually copy the change IDs. Unfortunately, they only provide functions for moving between the most recent commits that changes point to. To select a previous version of a change, the user must first open the obslog, and then copy the commit ID for the version they're after.

Solution

Introduce a set of functions for traversing the obslog. Much like parents(x) gives the parent change(s) of change x that can be found with jj log -r ..x, previously(x) would give the parent commit(s) of the change x that could be found with jj obslog -r x.

I'm proposing this set of functions where previously is the most useful and simple.

Obslog function suggestion	Analogous changelog function	Alias of
past(x)	ancestors(x)
future(x)	x..
previously(x)	parents(x)	oldest(past(x, 2))1

Operators would also be really nice to have, especially in cases like previously(previously(x)) but I'm not sure what symbol would be best.

Use cases

Verbatim "ours" rebase/merge #1027

I initially wanted this feature to carry out verbatim rebases. This is based on an idea from @ilyagr.

jj rebase -r a -d b
jj restore --to a --from 'previously(a)'

Unlike adding a --verbatim flag to rebase, this also allows restoring into a child of a so that the conflict resolution can be viewed before squashing into a.

Note that this is only equivalent to one type of git "ours" merge strategy. There are two subtly different types.

Restoring from a previous snapshot

Take this example

touch important # create an important file
jj debug snapshot # snapshot @
rm important # unintentionally remove an important file
jj restore --from 'previously(@)' important # bring the file back from the last snapshot

Footnotes

1. oldest doesn't exist but should be too hard to add since we have latest ↩

[emilazy]

I think I prefer previous()to previously(), but I suspect there’s lots of bikeshedding that could be done here.

There’s also the subtle difference between “this change ID at the previous op log version” and “this change ID at the previous obslog version” to consider.

[eopb]

I think I prefer previous()to previously(), but I suspect there’s lots of bikeshedding that could be done here.

That's fair. I considered previous but went for previously because I felt it conveyed better that it only goes a single layer deep, that being said, my reasoning may not work for others.

There’s also the subtle difference between “this change ID at the previous op log version” and “this change ID at the previous obslog version” to consider.

This is also related to #1283. Maybe we'll want to support both in the future. The obslog seems simpler and more useful to me, but both are interesting

[yuja]

Mercurial calls obslog-based resolution as predecessors/allpredecessors/successors/allsuccessors (analogous to parents/ancestors/children/descendants respectively.) I'll be nice if we can find better names for all* variants.

[ilyagr]

Copying from #4097, I think obsparents, obschildren, obsancestors, and obsdescendants are relatively clear. This also allows for obsroots and obsheads. We could also style them as obs_parents. Of course, these are not the prettiest names nor the shortest.

A related option would be to have parents(x, changes) for parents in the change-graph (AKA the normal graph, not sure if there is a better name) and parents(x, obs) for parents in the obsgraph. I'm not sure if this is a good idea as-is, but perhaps it'll spark other ideas.

[yuja]

Maybe evolution is better as a prefix? I think obsolete implies the direction towards predecessors (or ancestors in rewrites log.)

A related option would be to have parents(x, changes) for parents in the change-graph (AKA the normal graph, not sure if there is a better name) and parents(x, obs) for parents in the obsgraph.

Or obs(parents(x)), obs(::x), etc. Too cryptic? It's probably similar to how "branch set" would be expressed if we had such thing.

[emilazy]

I would personally like something fairly short for the UX of the restore use case. In that sense obs is nice, but on the other hand the obslog name itself always stuck out to me as awkward and out of place.

[PhilipMetzger]

Maybe the new names should consider #3592 whenever we get around that.

Maybe evolution is better as a prefix? I think obsolete implies the direction towards predecessors (or ancestors in rewrites log.)

A related option would be to have parents(x, changes) for parents in the change-graph (AKA the normal graph, not sure if there is a better name) and parents(x, obs) for parents in the obsgraph.

I do like this idea though.

I would personally like something fairly short for the UX of the restore use case.

I don't think this should matter for the name bikeshed, as you always can add aliases.

[yuja]

A related option would be to have parents(x, changes) for parents in the change-graph (AKA the normal graph, not sure if there is a better name) and parents(x, obs) for parents in the obsgraph.

Or obs(parents(x)), obs(::x), etc. Too cryptic?

It'll be nice if we can filter obslog by diffs from the predecessor.

jj obslog -r@- --obs '~empty()'

In revset, it might be expressed as obs(empty()), obs_empty(), or empty(obs).