Thus said David Mason on Sun, 05 Oct 2014 11:05:27 -0400: > + if ( statusFlag ) fossil_exit(nUpdate==0); > }
Before you start using this in your own fork, you might want to consider if having the update_cmd() function exit at this point will cause problems if FOSSIL_ENABLE_TH1_HOOKS is enabled when using statusFlag and there are no updates. I don't use FOSSIL_ENABLE_TH1_HOOKS (and maybe you don't either), but one side effect of causing update_cmd() to exit here means that FOSSIL_ENABLE_TH1_HOOKS code in main.c will not execute. Not sure if that is an issue. Someone who knows more about the #ifdef FOSSIL_ENABLE_TH1_HOOKS in main.c will likely know more: http://www.fossil-scm.org/index.html/info/394258fc8108f16ca99a8bac1a04fab209d53e7d?ln=757,765 I would look at other fossil subcommands to see if any of them exit (except those that call fossil_fatal &co. or exit with an error); my cursory glance seems to indicate that most fossil subcommands do not exit except for errors. I suppose perhaps the current intention is to have it exit with with a non-zero (aka error) exit status if nUpdate==0 so perhaps this is not such a bad change, but it does warrant some consideration for the case where it will exit without an error. At the moment, nUpdate==0 will always cause fossil to exit non-zero because it doesn't actually sync, so nUpdate would only ever be > 0 if you gave it a name to which Fossil can actually update, but it wouldn't mean that you have new sync content, only that there are changes possible from your current checkout to the new checkout requested. Thanks, Andy -- TAI64 timestamp: 40000000543239e2 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
