Why does jj log -p start with an old commit?

[BatmanAoD]

I was trying to figure out some weird output from jj log -p <file> and eventually figured out that jj log was using a commit from before the introduction of the selected file as its starting point. Sure enough, jj log -p -r @ <file> produced the output I originally expected.

The help string says that the default starting point for jj log is @ | ancestors(immutable_heads().., 2) | heads(immutable_heads()). I'm having difficulty understanding why this results in such an old commit.

Shouldn't | be maximally inclusive? That is, why would -r @ result in more commits being seen by jj log?

I'm not sure if this is something weird about my specific repo; if it is, I may not have time to build a minimal reproducible example any time soon.

(P.S. I've read the responses to my other discussion but need a bit of time to digest them and respond.)

[martinvonz]

I think you got most of that right:

• jj log defaults to showing commits in the set @ | ancestors(immutable_heads().., 2) | heads(immutable_heads()). However, that expression defines the full set of revisions to show, not the "starting point" (like git log's argument does).
• jj log <file> (with or without -p) intersects the set of revisions with those that modify the specified file
• | just unions, so -r @ should never include more commits than @ | ancestors(immutable_heads().., 2) | heads(immutable_heads()) does

The commits are necessarily ordered with children before parents (unless you pass --reversed). Between commits that are not related linearly (e.g. if they're siblings), we normally emit the one with the more recent commit timestamp first. That means that @ is often at the top, unless you've recently rebased some unrelated commits or fetched commits from a remote. Presumably, the commit you call "an old commit" is older than @ (maybe even an ancestor of it?), so I would expect it to be printed after @. You can run jj log -r '@ | <old commit> | heads(::@ & ::<old commit>)' to clarify the relationship between the two commits. If it's still unclear what's going on, it might be useful to share the output of that command here (feel free to redact non-public info from it if necessary).

[BatmanAoD]

Okay, I thought I had seen the problematic behavior (i.e. logs not including any recent commits) with jj log -p, but now I'm only seeing it with a filepath, the way I initially ran into the issue.

Here's the output demonstrating the problem:

❯ : jj log -p crates/log-parser/src/tools/charts.rs
warning: The argument "crates/log-parser/src/tools/charts.rs" is being interpreted as a path. To specify a revset, pass -r "crates/log-parser/src/tools/charts.rs" instead.

Here's the log command you suggested, where 25661e818... is the commit that most-recently touched charts.rs (i.e. the one I'd expect jj log -p <file> to show first):

❯ : jj log  -r '@ | 25661e8185a72b6f71daf402759d636f1ec0b0ab | heads(::@ & ::25661e8185a72b6f71daf402759d636f1ec0b0ab)'
@    tyllukww [email protected] 2023-10-30 12:56:39.000 -06:00 f1cf4798
├─╮  (empty) log-parser build
╷ │
╷ ~
╷
◉  muzmzwsr [email protected] 2023-09-20 23:40:57.000 +00:00 25661e81
│  Update: <omitted>
~

If I run jj log -p crates/log-parser/src/tools (i.e. the parent directory of the given file), the first commit I see is d1e1d931, from 3/16. Here's the command you suggested, using that commit:

❯ : jj log  -r '@ | d1e1d931 | heads(::@ & ::d1e1d931)'
@    tyllukww [email protected] 2023-10-30 12:56:39.000 -06:00 f1cf4798
├─╮  (empty) log-parser build
╷ │
╷ ~
╷
╷ ◉  nkppysot <other-employee>@rigetti.com 2023-03-16 15:40:01.000 -05:00 461-log-parser-execution-report d1e1d931
╭─╯  Display execute response report
◉  suskqstt <other-employee>@rigetti.com 2023-03-14 13:08:45.000 +00:00 v5.6.0 76160591
│  (empty) Merge branch '447-controller-logs-cli' into 'master'
~

One easy question I have from this: what is causing the log output here to be so minimal?

[martinvonz]

Oh, I think I see what you're confused about now. jj log defaults to that expression we talked about before, i.e. @ | ancestors(immutable_heads().., 2) | heads(immutable_heads()). What that means is roughly "the working-copy commit, plus commits that are not in immutable_heads(), plus some of the immutable heads for context". immutable_heads() is configurable but defaults to trunk() | tags(). The thinking is that users don't usually want to see all the history in their repo. You can override it if you want to see a different set of commits by default.

If you don't want to override the default in general but still want to see the full history in particular case, I think what you were looking for is jj log -r ::@ -p crates/log-parser/src/tools/charts.rs.

[BatmanAoD]

🤦🏻 I thought I saw jj log -r @ -p <file> show the expected 25661e81 commit, but in fact that's because I accidentally ran git log -r @ -p <file>.

Okay, so jj log -r <expr> only shows the commits in <expr>, not <expr> plus all ancestors. That makes much more sense; thank you.

I think that with -p, it probably makes sense to always use ::@ as the default...or maybe there's a way to take the path-based commit-pruning into account when determining the depth of ancestry to consider?

If nothing else, if log -p <path> returns no commits, it would probably be helpful to print a suggestion to use -r ::@.

[BatmanAoD]

FWIW, I think it's very cool that jj has this "revset language"... I just feel like it's going to take me a while to get used to it 😅

[martinvonz]

I think that with -p, it probably makes sense to always use ::@ as the default...or maybe there's a way to take the path-based commit-pruning into account when determining the depth of ancestry to consider?

I have also run jj log [-p] <file> and expected it to include ancestors. I can't remember if I also wished it had included other branches. It's not obvious to me which is better.

If nothing else, if log -p <path> returns no commits, it would probably be helpful to print a suggestion to use -r ::@.

Good idea! I'll file a feature request for tracking that.

[BatmanAoD]

I can't remember if I also wished it had included other branches.

Speaking for myself, I'd be pretty surprised to see any commits that aren't reachable from my working-copy state in the output of log -p <file>. That said, my use of log -p may be a little idiosyncratic; I tend to see it as a useful substitute for git blame when trying to figure out the rationale behind some piece of code.