Am I missing an easy way to get such information that already exists?

The "user" and "euser" ("edited user") fields of the "event" table (the timeline) are probably the easiest place to get that. IIRC, but this might be incorrect, the "euser" is set when the record is updated via the "edit" feature or "amend" command. All queries which display a user from that info use:

coalesce(euser,user)

(or similar) so that euser takes precedence. For a branch participation query, perhaps both names are relevant.

Would this be generally considered useful?

IMO yes. It would help me locate some of my older stale or out-of-date branches.

Related: any interest in getting a list of users that committed to a branch (which could be long, of course)?

It would make for interesting trivia, certainly. There's one tiny caveat which isn't a bug, per se, but is something to be aware of:

When user X merges a branch then that user is credited with the merge, even if the commit(s) which is/are merged are written by other people. That's why drh shows up as the initial author of the JSON API ;).

The "user" and "euser" ("edited user") fields of the "event" table (the timeline) are probably the easiest place to get that.

Thanks for confirming that. I currently include branches where the username matches either of them.

While I appreciate the distinction, my initial thoughts were more on participation.

I'll push what I have for --username and --self, then see if I can list users sensibly next.

FWIW, branch is up.

For a list of users, it gets very busy if there are many people involved, so I opted to require a limit. For Fossil, this is particularly noteworthy for trunk, of course.

Sample output, using a branch filter to show what list truncation looks like:

% ./fossil branch ls --users 3 -a "*ta[kl]*"
   diff-experimental (drh)
   diff-numstat-total (danield)
   experimental (drh,joerg,mistachkin,... 1 more)
   mistake (andybradford,andygoth,dg,... 4 more)
   msvc-warn2-fatal (larrybr)

Hello Preben

Some comments on the find_option() function from a quick glance at the "filter-branch-ls-by-user" branch:

• This line looks like the --self option has a short form -0, not mentioned in the command help text. Maybe change "0" to 0 to indicate there's no short form?

• This test wont't work: find_option() permutes g.argv and removes options and their arguments from the array.

Hi Florian,

This line looks like the --self option has a short form -0

You are absolutely right: It should be a 0, not a string. Thank you.

This test wont't work: find_option() permutes g.argv and removes options and their arguments from the array.

The test is specifically aimed at --users being the last command line argument, but without a value.

AFAICT, if you run fossil branch ls --users, find_options() will bail out early on the last flag as an argument is expected:

  for(i=1; i<g.argc; i++){
    char *z;
    if( i+hasArg >= g.argc ) break;

That, btw, I think is a bug, as it does not handle e.g. --users=5 as the final command line argument.

The reason I added the check, is that --users would otherwise be treated as a branch name filter, so the command would just silently not produce any output.

BTW, I misspelled "--users" as "--user" in the test you pointed to. I pushed a fix for the 0 above and this.

OK, so I think the proper way to check for the missing --users argument is to add a verify_all_options() call.

This was currently missing in the fossil branch ls argument handling, and I was trying to work around that without realising there was a better way.

Thanks for getting me down this path

... add a verify_all_options() call ... This was currently missing in the fossil branch ls argument handling ...

Yes, that kept me awake for a while last night! The verify_all_options() call was missing because fossil branch ls allowed one or more branch glob-patters to look like options, i.e. starting with a dash! But later, support for the stop option mark -- was added to verify_all_options(), and so calling it from this command seems fine, since branch glob-patterns looking like options can now be guarded by --. Your initial approach made sense in this context, but now we also have -- support.

That, btw, I think is a bug, as it does not handle e.g. --users=5 as the final command line argument.

Can we fix this without breaking anything?

Oh dear, I skipped the word final, and obviously I've only ever tried the --option="argument" format with the last argument. So of course this should not cause any compatibility issues, and can be corrected. Thanks for the fix!

Unfortunately, the fix broke detection of a final -F flag when an argument is expected. I updated the branch.

The test is specifically aimed at --users being the last command line argument, but without a value.

Ok, I see. Probably I was more about consistency, i.e. just let verify_all_options() kick in and handle this, see the analogous case with a missing option argument:

$ fossil br new x current --bgcolor
unrecognized command-line option or missing argument: --bgcolor

Moreover, find_option() would also allow -users (with only one leading dash), which may also cause confusion if testing for --users (with two leading dashes) explicitly.

That, btw, I think is a bug, as it does not handle e.g. --users=5 as the final command line argument.

To my recollection as a user, Fossil has never handled long options joined with = and their arguments, at least as far as I can remember -- but indeed from looking at the source code, this should work? So maybe a bug... Can we fix this without breaking anything? Steeephaaan...!?

Oops, sorry for x'ing!

No worries as far as I am concerned -- I'm learning from your input!

In case Stephan reads this, please check a proposed fix for the handling of --opt=val as last argument.

[Edited to fix a spelling error in a name, my apologies.]

... please check a proposed fix for the handling of --opt=val as last argument.

Like Florian, i did not know that we had code to handle the --X=Y case. We never use it and have never documented it. Your change looks correct to me but i've not tried it out.

Edited to fix a spelling error in a name, my apologies

LOL! My mother spelled my name one way and pronounced it another, so nobody but she and i really knows the correct way to spell or pronounce my name ;). i answer to all variants of the name and take no offense at all to "misspellings." (i grew up in the States, where my name's spelling is wrong, but have spent the past 26 years in Germany, where the spelling is correct but the pronunciation is wrong! Which pronunciation i use depends on who i'm speaking to, and i frequent switch between "Steven" and "Stefan.")

I must admit, I'm not picky myself. As a Dane in The Netherlands having had English as professional language for 20+ years, I'm nearly as confused about the way to pronounce my name as most others.