log node template: mark empty un-conflicted commits with ◌

[ilyagr]

This is useful to see which merges resolve conflicts and to more easily sort WIP commits.

---

I don't remember whether this was discussed when we were originally changing the symbols. My main worry about this is if Chromebooks or some other systems don't have this symbol in their default fonts.

---

Some ideas I thought about and decided against:

• ∅ looked too messy

• I considered using green for "empty", and yellow for "non-empty working copy", but I think the dotted circle is visible enough and making the working copy stand out is more important.

• There's the option of using ○ for empty commits and ● for non-empty, but I personally feel like so many ●s would look too heavy for my taste.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes

[martinvonz]

Checking whether a merge commit is empty can be slow on large repos. Can you check if this has significant impact on e.g. the Linux repo?

[ilyagr]

As long as if(immutable) is present before if(empty) in the template, the performance isn't affected as long as most commits in the repo are immutable. So, out of the box, there is no difference in performance.

If I artificially remove it, there is a difference. Here are the two configs:

# Empty node
# Note the if(false && for the removed condition
log_node = '''
coalesce(
  if(!self, label("elided", "~")),
  label(
    separate(" ",
      if(current_working_copy, "working_copy"),
      if(immutable, "immutable"),
      if(conflict, "conflict"),
    ),
    coalesce(
      if(current_working_copy, "@"),
      if(false && immutable, "◆"),
      if(conflict, "×"),
      if(empty, "◌"),
      "○",
    )
  )
)
'''

and

# No empty node
[templates]
log_node = '''
coalesce(
  if(!self, label("elided", "~")),
  label(
    separate(" ",
      if(current_working_copy, "working_copy"),
      if(immutable, "immutable"),
      if(conflict, "conflict"),
    ),
    coalesce(
      if(current_working_copy, "@"),
      if(false && immutable, "◆"),
      if(conflict, "×"),
      if(false && empty, "◌"),
      "○",
    )
  )
)
'''

The result for the linux repo:

$ hyperfine --warmup 1 'jj log --no-pager -r :: --limit 1000 ' # No empty node
Benchmark 1: jj log --no-pager -r :: --limit 1000
  Time (mean ± σ):     771.3 ms ±  29.8 ms    [User: 643.3 ms, System: 96.2 ms]
  Range (min … max):   736.2 ms … 846.3 ms    10 runs

$ hyperfine --warmup 1 'jj log --no-pager -r :: --limit 1000 ' # Empty node
Benchmark 1: jj log --no-pager -r :: --limit 1000
  Time (mean ± σ):      1.177 s ±  0.025 s    [User: 1.040 s, System: 0.108 s]
  Range (min … max):    1.147 s …  1.216 s    10 runs

Again, the difference disappears (and it gets 10 times faster) if I re-enable the immutable symbol.
We could in theory speed things up if the log_node template and the log description template could reuse the same cache of information. I have no idea how difficult that would be.

[martinvonz]

My main worry about this is if Chromebooks or some other systems don't have this symbol in their default fonts.

I think my main worry is that it might not be clear to people why some commits have a different symbol, but we already don't explain the symbol for immutable commits, for example, so maybe it's not a problem.

[ilyagr]

I am not sure what the conclusion should be about whether this is worth the convenience. If not, I can put this into the docs instead of changing the default.

[ilyagr]

My main worry about this is if Chromebooks or some other systems don't have this symbol in their default fonts.

I think my main worry is that it might not be clear to people why some commits have a different symbol, but we already don't explain the symbol for immutable commits, for example, so maybe it's not a problem.

That's fair.

Ideally, we should find a place to explain the immutable symbol. If we do, the empty symbol could probably be explained in the same place.

[yuja]

I think doc example is better. People who like to encode much information in graph nodes would have their opinions about node symbols/colors, and customize their templates anyway.