Can you please add an option to the LEAVES command for showing the earliest/first commit comment?

i'm not convinced: you're asking for a feature that solves only your particular workflow (leaving code that the developers then have to maintain forever). There's no guaranty at all that the comment on the branch-point commit is in any way more informative than the leaf comment it: that's a simply your way of doing things, not a technical requirement. It seems likely to me that mixing checkin messages for the leaves would cause more confusion than it solves.

As an alternative: what if the leaf showed the checkin ID of the branch point, so that you would then have a piece of information you could follow to find more information? That sounds generically more useful to me.

So, something like this mock-up:

$ f leaves
...
   (2) 2014-11-21 15:57:02 [3104155e44] ...  (user: dave tags: feech-VerSetVtblXtnCbk) Branched from: [abacabdecaf]
...

To get more information from that branch point, including its checkin comment:

$ f whatis abacabdecaf
# or:
$ f info abacabdecaf

you're asking for a feature that solves only your particular workflow

That's an assumption as you can't possibly know everyone else's workflow.

The problem with your proposal is that for each candidate branch you have to do one extra step to find if it's the one you want. So, it's tedious.

Consider you have multiple branches for the same new feature implemented in different ways so that you can eventually compare and choose which will become trunk:

method1
method2
method3

Now, methods 1, 2, or 3 (or many more) are short names to type, and you'd want to keep them short.

After some time (days even) you're not really sure which of them implements what exactly. A longer detailed description is required. This is more often than not found in the very first commit for that branch.

With FOSSIL LEAVES --first you will be able to immediately see with a single command all pertinent information. What's simpler than that?

That's an assumption as you can't possibly know everyone else's workflow.

And yet i know for a fact that it's not everyone's workflow. As a fossil project policy, we try not to enforce project-level policies on users, and the addition of a separate checkin's comment falls (IMO) into that category. Rather than outright reject your proposal, though, i'm offering an alternative which provides the requested information plus a whole lot more.

A longer detailed description is required. This is more often than not found in the very first commit for that branch.

My proposal gives you not only the context-less comment, but all information about the branch point, in the form of its hash.

With FOSSIL LEAVES --first you will be able to immediately see with a single command all pertinent information.

"All pertinent information" is not contained in the checkin comment of the branch, but it is included, just one step removed, with the hash.

What's simpler than that?

My proposal wouldn't require a new flag to make use of it and provides a low-friction path to "all pertinent information" for those who want to follow it.

What's simpler than that? ;)

Seems like a new option to "fossil branch list" would be a more appropriate place for this, if it gets implemented at all.

Here's an example of what my proposal would look like:

https://fossil-scm.org/home/timeline?r=leaves-command-branched-from

$ f leave | head
   (1) 2021-02-15 15:50:51 [20391d1e58] Internal API additions in symbolic_name_to_rid(). (user: stephan tags: trunk)
   (2) 2021-02-14 21:28:19 [0516f4d3c8] Brought graham's ui-local-diff branch <SNIP> style guidelines. (user:
       wyoung tags: ui-local-diff) (branched from: [2c9aa1b939])
   (3) 2021-01-19 08:09:15 [1743f89a0a] Adjustments to <SNIP> that for now. (user: drh tags: mistake) (branched from: [fb3dabd5c4])

This seems somewhat useful to me, but i'm not personally aching to have it, so i'll leave it up to Richard and the rest of y'all to decide whether it's worth having.

The one glaring unsightliness is that this implementation assumes that the name "trunk" is magical and leaves (haha) that information out for the trunk-branch(es) listing(s). That's arguable, but if we don't do that then it can, as in the case of the main fossil tree, calculate a really, really ancient branch point for the trunk:

$ f leave | head
   (1) 2021-02-15 15:50:51 [20391d1e58] <SNIP> tags: trunk) (branched from: [c06edd231f])
...

$ f whatis c06edd231f
name:       c06edd231f
artifact:   c06edd231fc15d145a1c96c39b8fecdb79b33523
size:       16458 bytes
tags:       clear-title
raw-tags:   closed
type:       Check-in by drh on 2010-05-16 19:08:45
comment:    Change from GPL to the Simplified BSD Lice

The one glaring unsightliness is that this implementation assumes that the name "trunk" is magical and ...

There is a config setup item called 'main_branch'. That would be better than magic, IMHO.

There is a config setup item called 'main_branch'. That would be better than magic, IMHO.

Good call - i had forgotten main-branch. Done, defaulting to "trunk" if that option is not set. (main-branch is a local config option, not part of the persistent project settings, curiously enough. We had a long discussion about that here in the forums a year or two back, but i'm not finding it via search.)

On local versus project for that setting, the Help: main-branch page says, "The value is the primary branch for the project." So I doubt that a long discussion could be had today on the issue. (That's not a challenge!)

"The value is the primary branch for the project." So I doubt that a long discussion could be had today on the issue.

That was kind of the problem, actually. It seems like a reasonable assumption that it's a sync'd project-level setting, but it turns out that i have no business imposing my main-branch value on you, so that config option does not sync and is not a versionable setting.

Ah, here we go: /forumpost/5b3e73dc78

Not quite a year ago. Seems like much longer.