Open eopb opened 3 months ago
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.
I think I prefer
previous()
topreviously()
, 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 https://github.com/martinvonz/jj/issues/1283. Maybe we'll want to support both in the future. The obslog seems simpler and more useful to me, but both are interesting
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.
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.
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) andparents(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.
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.
Maybe the new names should consider #3592 whenever we get around that.
Maybe
evolution
is better as a prefix? I thinkobsolete
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) andparents(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.
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) andparents(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)
.
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 changex
that can be found withjj log -r ..x
,previously(x)
would give the parent commit(s) of the changex
that could be found withjj obslog -r x
.I'm proposing this set of functions where
previously
is the most useful and simple.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 https://github.com/martinvonz/jj/issues/1027
I initially wanted this feature to carry out verbatim rebases. This is based on an idea from @ilyagr.
Unlike adding a
--verbatim
flag torebase
, this also allows restoring into a child ofa
so that the conflict resolution can be viewed before squashing intoa
.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
[^1]:
oldest
doesn't exist but should be too hard to add since we havelatest