Thus said Matt Welland on Mon, 13 Apr 2015 15:57:53 -0700: > Does fork notification really warrant another setting?
Generally, I would prefer to avoid another setting, but wanted to make sure. > Forks are rare in most repos (the intensely busy repos I deal with > seem to be the exception). Given these points surely a fork warning is > a harmless or at worst mildly annoying rare occurrence so please make > it the default behavior or make it non-configurable. I agree that for repositories where forks are rare, it is a minor nuisance at worst. It may be helpful in most cases if the fork didn't get noticed for a while, but it may also alert people who are disinterested (e.g. working on a branch in which there are no forks) if the fork isn't merged before they pull it in. I suppose notifying the committer that a fork has occurred during their sync operation may cause the fork to be merged more quickly thus minimizing the number of folks who will actually see a warning. If my SQL is correct, there have been 74 forks in Fossil since 2007. It would seem that many of the early forks were due to either not having branching, or using the fork as the branch. Later commits to Fossil seem to involve fewer forks and more branches. This year so far has only seen 1 unintentional fork: http://www.fossil-scm.org/index.html/timeline?n=25&y=all&v=0&c=2015-03-30+20%3A34%3A39 It would seem that the frequency of forks is low for Fossil. I suppose worst case, we merge sync-forkwarn to trunk and see how it fares prior to the next release. Andy -- TAI64 timestamp: 40000000552c8ccd _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
