Frequent jj log elided revisions spam

[RossSmyth]

Hello, I love JJ except for one thing: jj log is often unusable for me.

I often work on nixpkgs and rustc. These have many committers and commits. Something about this seems to make jj log confused, because it will be fine, then I'll see something like this:

or this:
https://github.com/user-attachments/assets/20dc1808-79c6-4558-b446-d52e13fa92bf

This is unusable. I do not know what I did to get it in this state, as it was fine one moment, then not fine the next. Sometimes it just seems to resolve itself, sometimes I just nuke the repo and reclone it. My config has the default command as log --reversed. But when this happens I run jj log --limit 4 or something similar.

Does anyone know why this happens, and how I could fix it? Maybe I should open an issue because really this is an unacceptable UX flaw.

[PhilipMetzger]

A merge-heavy graph will always lean to the right, see the related discussion about adding a --first-parent equivalent (#6606). @emilazy another Nixpkgs commiter also has reverted to using git log --first-parent in the repo now.

[RossSmyth]

The problem is that it looks fine, but then I'll do something that should be fine (rebase to another commit bookmark that is currently shown, git fetch) and it suddenly becomes unusable. So it is extremely unstable in terms of being usable or not.

[emilazy]

FWIW I mostly use jj log to look at my own work. I only use git log for things like reviewing changes to a given file (for which Jujutsu is hopelessly slow).

I think --reversed is a bad idea for a merge‐heavy repo but also it seems like your revsets.log is giving bad results, possibly because of your tracked bookmarks or immutable heads setting?

[RossSmyth]

I only have a few tracked bookmarks. The main issue is that it is very unstable. It will be fine, then some seemingly innocuous operation will lead to an unreadable output.

[RossSmyth]

For example today I nuked my nixpkgs clone and recloned it. I cloned my msEdit branch and it is already mostly unusable. For some reason it doesn't elide many commits.

[jennings]

Commits aren’t elided automatically. If you see a commit in the log, it’s because it was selected by the revset.

You see “elided commits” in the log when the revset selects a commit and its ancestor, but not a commit between them the “elided commits” message is there to let you know that something is missing.

nixpkgs is an idiosyncratic repo and so you probably want to use a revset that omits more immutable commits than you normally would. I would try something like @ | trunk() | mutable() to get started. If you want a little bit more context, you can wrap it in ancestors(REV, 2): ancestors(@ | trunk() | mutable(), 2)