This will make it easily available everywhere so we can get more
detailed information about arguments passed to commands. In
particular, I think it can be useful for displaying different hints
depending on whether the user passed `-r @` or if the `@` revision was
from the defaults.
We could add `walk.descendants(root_positions)` method, and apply
`.filter_by_generation(range)`, but queue-based `.descendants()` would be
slower than the one using reachable set. So I didn't add such method.
I also considered reimplementing non-lazy version of this function without
using the current RevWalkGenerationRange, but it appears the current iterator
version performs well even if we have to do .collect_vec() and .reverse().
This helps to extract a trait that abstracts CompositeIndex and descendants
map. Since the entry type E is a newtype wrapper, there wouldn't be runtime
cost.
I'm going to add a RevWalk method to walk descendants with generation filter,
which will use this helper method. RevWalk::take_until_roots() uses .min()
instead of .last() since RevWalk shouldn't know the order of the input set.
Before, the number of the generations to track would increase at each merge
point. This was really bad for queries like ':@--' in merge-heavy history,
but I didn't notice the problem because ancestors query is lazy and
the default log template is slow. Since I'm going to reuse RevWalk for
'roots++:' queries, which can't be lazy, I need to fix this problem first.
As we don't have a revset expression to specify exact generation range,
gen.end is initialized to either 1 or close to u32::MAX. So, this change
means long-lived generation ranges will eventually be merged into one.
If "jj op undo" doesn't roll back git refs (#1541), test_git_import_undo()
would get weird state. I think these tests are easier to follow than
test_git_fetch_undo() since no remote refs are involved.
This doc describes what we need to consider in a submodule storage
solution, some possible solutions and what criteria we should use to
decide on a future direction.
This is still a WIP:
- The solutions are still underdescribed
- The actual evaluation of solutions is missing
Suggestions for the above are welcome :)
The substitution rule and tests are copied from ancestors/parents. The backend
logic will be reimplemented later. For now, it naively repeats children().
This is a minimal change to replace Children with Descendants. A generation
parameter could be added to RevsetExpression::DagRange, but it's not needed
as of now.
I'm going to add generation parameter to Children/DagRange nodes, and
'Children { .. }' will be substituted to 'DagRange { .., gen: 1 }'. This
commit helps future code move.
Lifetime bounds of the arguments are unnecessarily restricted. It appears
walk_ancestors_until_roots() captures arguments lifetime on rustc 1.64.0.
I think the problem will go away if walk_*() functions are extracted to
RevWalk methods where input arguments will become less generic.
It doesn't matter, but can simplify the function interface. I'll probably
extract this function to RevWalk so the descendants with/without generation
filter can be tested without using revset API.
"jj show" is basically a "log" command with different defaults. We'll need
to consider this kind of stuff if we want to introduce namespace to templates.
I think we should test actually performing the push when possible. I
think I initially used `--dry-run` because I thought it wasn't
possible to do local pushes with libgit2.
Establishing a unique file extension for the temporary files created
via `jj describe` helps to ensure that text editors can recognize the
filetype and alter settings accordingly. This will open the door for
an improved user experience, and allow for setting things like the
appropriate text-width/rulers, syntax highlighting of the diff summary
(see Git's commit tree-sitter grammer [1]), easy toggling of the `JJ:`
comment lines, etc.
I examined the behavior of filetype detection across a number of
common text editors, and the most universally-support mechanism was
to have a unique extension that does not include any periods. Meaning
that namespacing via something like `.jj.txt` instead, won't always be
detected due to inconsistent matching prioritization across editors.
It also makes sense to assume that we may want other Jujutsu-specific
filetypes in the future.
The filename prefix has also been switched to be `editor-` for clarity,
as well as to ease matching a glob-pattern if we ever need to garbage
collect leftover tempfiles. This structure is similar to what Mercurial
and Sapling do as well.
[1] https://github.com/the-mikedavis/tree-sitter-git-commit
It no longer needs to be on the `Index` trait, thereby removing the
last direct use of `IndexEntry` in the trait (it's still used
indirectly in `walk_revs()`).
The need for a glossary came up on Discord today.
This needs some more work, but I think this is a good start. I'm still
happy to update it if anyone has suggestions, of course. I haven't
started sprinkling pointers to the glossary from other places, so
users will only discover it by browsing the `docs/` directory.
This is a convenience optimization to improve the default user
experience, since `jj log` is a frequently run command. Accessing the
help information explicitly still follows normal CLI conventions, and
instructions are displayed appropriately if the user happens to make a
mistake. Discoverability should not be adversely harmed.
Note that this behavior mirrors what Sapling does [2], where `sl` will
display the smartlog by default.
[1] https://github.com/clap-rs/clap/issues/975
[2] https://sapling-scm.com/docs/overview/smartlog
