FR: a template function to measure the shortest distance between two commits

I see you've linked some other issues for motivation, but I'll just comment here and depend on you to propagate out as needed :)

A couple thoughts:

• jj log --count already mostly does this. I know you said an additional command invocation is not ideal (which makes sense), but just calling it out since you didn't mention it in the FR. (But also see note below.)
• This FR is asking for a revset function, but that makes little sense since the revset language is for selecting a set of revisions, and numbers are not really useful in that context as the output of a function (since all revsets are supposed to evaluate to a set of commits, what does it mean for the result to be a number?). You probably meant "a template function to measure distance", since the templating language is for outputting information about revisions and other objects.
  • You also mentioned in the other issue that you're a recent convert to jj (welcome!), so perhaps the distinction is not yet clear to you. Totally fine, of course there's a learning curve; just wanted to make sure the FR makes sense.
• #10150 was recently merged (but not released yet), which adds a revset() function to the templating language. This means that you could count the size of a revset by doing revset("mutable()").len(). This is essentially the same as --count, but does so in the context of a template (and may also be slower because it will probably eagerly fetch all the commits instead of just reporting the size, but this may be an unsubstantiated claim).

Note about --count

I show a distance in my prompt (don't use Starship though), so here are some problems I've encountered with counting "distance"...

jj log --count counts the number of revisions that would have been printed in the graph. If you want the "distance" between x and y (assuming they're single commits), then you could just do jj log -r x..y --count (this revset is equivalent to ::y ~ ::x = x::y ~ x (note that the RHS is true because x and y are single commits!); usually "distance" in this context does not include both endpoints). However, this only returns the correct answer if x..y is a linear chain, which isn't always the case. For example, if you have something like this:

  y
 / \
o   p
|   |
m   n
 \ /
  x

Then jj log -r x..y --count will return 5 when in fact you probably wanted 3. Maybe you could try to use first_ancestors then, so that only one path is followed:

$ jj log -r 'first_ancestors(y) ~ ::x`
  [y]
  / \
[o]  p
 |   |
[m]  n
  \ /
   x

This will return 3, which is good. But wait, what if the other branch doesn't have the same number of commits?

  y
 / \
o   |
|   n
m   |
 \ /
  x

In this case, does "distance" mean 3 or 2? If you always want the shortest or the longest distance, that's not possible because there's no way to know which path to take, and there are only ways to traverse the first parent edges, and there may be much more complicated graphs between x and y. I even think it's probably not generally possible to say "I always want the path through n or something like that. So basically, you need a proper definition of "distance", or you need to be satisfied with the first parent path.

My solution to this (I was actually working on this last night, coincidentally) is to jj log without --count and use a template to output the commit IDs of the parents (parents.map(|p| p.commit_id())). I then walk all the parent edges myself using BFS to find the shortest distance between x and y. I haven't done extensive timing tests yet, and it seems to be only a tiny bit slower (~20 ms slower than --count), but I believe --count is supposed to be much faster because it knows you only want the size. But I'm also trying to optimize some other templated output in a single jj log call, so it might be making up for that a little bit.

Also, this problem is also present with the revset() templating function that I mentioned above, since it's also using a revset without specifying which paths to take and then just looking at the size of the result.

So the conclusions of my wall of text are:

• You can use --count or revset() to get an approximation of "distance".
• Non-linear chains of commits are hard.
• If such a function is added, the notion of "distance" needs to be clearly and rigorously defined.
  • Different people may have different definitions. I don't know if it's necessary to provide multiple different "distance" calculations.

It may also be the case that "distance between commits" is already commonly defined in the VCS world and I'm just unaware. In that case, I hope this rant was at least interesting, even if not useful :p