I had not thought of the situation when adding a tree.

To some extent copyInheritedSettings() is (was) low -level routine, and making it recursive means it is a bit higher level. Still thinking about it, but probably recursive is most useful behaviour and no need to make configurable in first instance.

At the risk of making the .copyInheritedSettings() behavior more confusing, I suggest making calls to it with no arguments result in inherited settings being copied from this to all its descendants.

Use case: want to change behavior of an entire command hierarchy when the root command is returned from a function with all subcommands already registered (like in https://stackoverflow.com/questions/76896860 first referenced in #1917 (comment)), for example for testing purposes (setting exitOverride like in the example etc.)

Even with changes introduced in this PR, the .commands array would still have to be iterated to achieve the desired result. If the new suggestion is accepted, one call will be enough.

Could also dump this PR if the suggestion is accepted. The change would be non-breaking then.

Currently copyInheritedSettings does one simple thing, which I like. It exposes what used to be an internal step so authors can use it for assembling commands. I don't like making routines more flexible (and complicated) without a clear vision. In your case, you are already wondering about two different implementations. My instinct is not clear enough yet (i.e. I want to see another/other issues).

Given it is easy enough for author to implement exactly what they want, and I think a different approach would be better for the .exitOverride() example, I am going to close this for now.

The apply-settings-after-creating-program situation might be handled by something like:

program.recursiveSet((cmd) -> {
   cmd.exitOverride();
   cmd.helpOption('-a, --assist', 'assistance');
});

The apply-settings-after-creating-program situation might be handled by something like:

program.recursiveSet((cmd) -> {
   cmd.exitOverride();
   cmd.helpOption('-a, --assist', 'assistance');
});

.recursiveSet() would just have to do exactly what a .copyInheritedSettings() call with no arguments would do in my suggestion, just after calling the callback function. There is no need to make it so complicated.

In your case, you are already wondering about two different implementations.

It's a good thing this PR was kept open long enough for me to come up with a better idea :)) I think just adding support for the call with no arguments is great because the suggested behavior is likely what most users really want when they use .copyInheritedSettings(), but at the same time, the change wouldn't be breaking and finer control would still be possible in cases where it's needed.