So I would perhaps try to make this more flexible and to more closely match the svn syntax (this is akin to 'svn resolve --accept working') by supporting 'etcupdate -a <mode>' where 'mode' is one of the prompt options (but not 'p', just 'mf' or 'tf' and possibly the 'mine-full' and 'theirs-full' aliases). In that case I would probably call the variable "resolve_mode" or some such (automated means different things to different people and I think it is too ambiguous to use here).

Also, as implemented this only affects 'etcupdate resolve' but not 'etcupdate' (the default command). The manpage and usage are incorrect, but I actually think it would be more useful to be able to specify this option for the default command, but that means changing the logic in merge_file() to consult the 'resolve_mode' and only call new_conflict if it does not specify a valid mode. (This means you could also specify 'resolve_mode=mf' in /etc/etcupdate.conf to change the default without having to alter the command line invocation for TrueOS if you wished and not having to call 'etcupdate resolve', just 'etcupdate' itself.)

Finally, there are some existing tests for etcupdate that test conflicts. It would be good to extend those to test that the new conflict modes work as well.

Also, one thing that may not be clear from the commit log: etcupdate already doesn't prompt for the "default" command. It is only "etcupdate resolve" that prompts the user. If you are currently only using '-a' with 'etcupdate' currently then this change isn't actually doing anything as it only changes the behavior of 'etcupdate resolve'. (One reason one might want a default resolve action though is that 'etcupdate' refuses to perform an update if there are previously-unresolved conflicts from an earlier run.)