On Fri, Jul 21, 2023 at 10:54:58PM +1000, Mark Jamsek wrote:
> This is a simple change along the same lines of showing reference labels
> next to tog log messages insofar as it improves situational awareness,
> which can be handy at times.
> 
> For example, in the case where you want to fold or drop some commits.
> After 'got up -c:head:-N', I often like to confirm I've updated to the
> correct commit before invoking histedit. With this, you can open tog and
> at a glance confirm that your base commit is indeed the correct one for
> the desired histedit operation. Similarly, when your base commit is
> something other than the tip, it's nice to know where the base commit is
> in relation to the rest when browsing the log view. This can interop
> well with the new :base keyword feature.
> 
> The change will be immediately obvious upon running tog with the patch
> inside a work tree, but to summarise: we show the "[base commit]" label
> in the log view headline if the currently selected commit is the work
> tree's base commit; and, irrespective of which commit is selected, we
> prepend the base commit's summary log message with the '@' symbol. There
> is no change to the log view when tog is invoked outside a work tree.

I agree that this is useful.

Some things I would suggest to change:

Could we use * instead of @, for consistency with got branch -l?
And like got branch -l, could tog show ~ if the work tree is out of
date with respect to the branch tip?

A problem that applies to both this patch and got branch -l:
A mixed-commit work tree will be displayed as up-to-date since the current
logic only considers the work tree's global base commit.
Could we iterate over the file index and check whether any file is based
on a different commit, and if so show the out-of-date symbol ~?

It is a matter of taste but the [base commit] marker seems redundant to me
and makes the display seem too crowded. I would omit this marker for now.