Thus said Matt Welland on Sat, 25 Apr 2015 15:05:54 -0700: > Our preferred work style is to get feedback from the command line > where possible. If notified of a fork during update, sync or commit a > developer may resort to the UI to determine what happened but the fix > is done at the command line.
While the change is not yet in an official release (it's now merged to trunk, but definitely in ``testing'' mode), would you mind trying the latest to see how it works in your environment: http://www.fossil-scm.org/index.html/info/560483f50436c9f7 > From reading the posts it seems quite a few people on this list either > perceive or experience forks differently that myself and others on my > team. Perhaps because we have not experienced the large number of forks that you are encountering. The last time I checked, there were not yet 80 forks in Fossil in it's entire not yet 8 years of existence. Not very many to be sure. How many do you have in 1 day? 1 week? 1 month? > A fork is seen as a failure of fossil to handle a commit that requires > tiresome manual intervention to fix. Perhaps because the person who committed the fork was not aware of it, nor was anyone else? If someone had been alerted to the presence of the fork, would it have been dealt with when it happened? Thanks, Andy -- TAI64 timestamp: 40000000553c6ec8 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
