First parents

[whatisaphone]

Warning: I'm only 90% confident about my knowledge here, so bear with me. With that out of the way:

The "first parent" of a commit is special in git (and jj). When you run git checkout x; git merge y z, or jj new x y z, the resulting commit has x as the first parent. There's nothing special about the last parent.

I'll deliberately create these commits in a weird order, to show that jj treats topology as more important than timestamps:

jj git init --colocate

for x in feat2 main feat1; do
    jj new zzz
    touch $x
    jj desc -m$x
    jj bookmark create -r@ $x
    sleep 1
done

jj new main feat1 feat2

jj log

@      zxtwpkkt 🪞 2025-08-14 13:47:39 2a8efa3e
├─┬─╮  (empty) (no description set)
│ │ ○  lzmopwlm 🪞 2025-08-14 13:47:36 feat2 7181995a
│ │ │  feat2
│ ○ │  pptnsmlx 🪞 2025-08-14 13:47:38 feat1 874cd992
│ ├─╯  feat1
○ │  syyrkvtn 🪞 2025-08-14 13:47:37 main git_head() 9bd56cf1
├─╯  main
◆  zzzzzzzz root() 00000000

jj new main feat1 feat2 merges feat1 and feat2 into main (the first parent). The first parent is semantically the trunk in that operation. jj log prioritizes laying out first parents down the leftmost side of the graph, regardless of commit timestamps.

There are 3 places I found that jjui doesn't respect first parents the way I expect:

1. I start jjui, interactively check main, then feat1, then feat2, then hit n. jjui will pass the commits to jj new sorted from newest to oldest (jj new feat1 main feat2), but I'd expect it to preserve my explicit order (jj new main feat1 feat2).
   • This means if your feature branch is newer than your trunk, and you use jjui to merge, the merge ends up backwards
2. If I hit shift-j on a commit, jjui seems to jump to the newest ancestor (ordered by timestamp), but I'd expect it to respect the repo topology and follow the chain of first parents.
3. The bookmark menu b shows move $bookmark to $current_change options, sorted by each $bookmark's timestamps from newest to oldest. But I'd expect them to be sorted topologically by parent order. e.g. a bookmark reachable by traversing the first parent should be sorted before a bookmark reachable only from the second parent, etc
   • This would mean that the branch you merged into is the first/default option for which bookmark to move. With jj new main feat1 feat2, main is the trunk and jjui should default to moving main rather than feat2. This is afaik always what you want

Is there any reason jjui shouldn't change to behave like I described?

[idursun]

Hey, thanks writing this up!

1. makes sense, I will look into why that's the case. I have a hunch that the order is not preserved because the underlying data structure that holds the selected revisions is a map and it doesn't preserve the order.

I will have a look at the other ones once I am done with the first one.