On Fri, Mar 31, 2023 at 11:31:16AM +1100, Mark Jamsek wrote:
> I'm a bit torn. On the one hand, I think got already provides for this
> use case. It's as simple as `got info`, read the base commit, then
> `{got,tog} log -c abc012`. If it's done frequently, I'd probably alias:
> 
>   tog log -c $(got info | grep base | cut -d' ' -f5)
> 
> Adding more options to do something that is already easily doable seems
> like a path to too many options.
> 
> On the other hand, I like the 'log -c BASE' suggestion; it reminds me of
> mercurial revsets, which are quite nice. And we also offer something
> similar in Fossil with special terms  like: 'current' for the current
> checkout; 'next' for the child of the current checkout; and 'prev' for
> the parent of the current checkout. I use these often. So of the two
> proposed solutions, I'd prefer going that route.

I am fine with adding such keywords to -c.
We would need to ensure that this feature works consistently across all
commands. Quite a bit of work might be involved in this, for test cases
in particular.

> I'm quite busy for the next week or so but will have spare time to hack
> on got from April 9. I was going to polish the tog test harness diff but
> I can do this first if we want to pursue the BASE idea.

A tog test harness has much higher priority in my book :)
Even if it's just adding very basic coverage at first, having this code
in-tree such that others can contribute to it and add more test cases
would be very nice.
Our lack of automated tests for tog has already bitten us in the past.