On Sat, Apr 25, 2015 at 10:20 PM, Ron W <ronw.m...@gmail.com> wrote: > On Sat, Apr 25, 2015 at 6:05 PM, Matt Welland <mattrwell...@gmail.com> > wrote: > >> A fork is seen as a failure of fossil to handle a commit that requires >> tiresome manual intervention to fix. >> > > But, doesn't a blocked merge due to a pull that results in a fork require > significant manual intervention to resolve? > > It's all well and good to say that it is the responsibility of the > contributor to re-base and submit again. But the core dev who initially > accepted the contribution has to somehow un-merge that contribution from > her local repo. > > Adding to what Andy pointed out, I would say that the problem was more > that there was not sufficient notification of the fork than that the fork > occurred. > > I suspect that if the fork had been noticed immediately, the effort to > resolve would not have been as significant as when discovered later. >
By "tiresome" here I mean only that it is tedious due to being work that adds no value per se. Almost all forks are trivially corrected with "fossil merge;fossil commit -m fixed-fork". In fact it is so mechanical that 99/100 forks could be fixed by something like: for b in $(fossil branch|tr '*' ' ');do fossil up $b fossil merge fossil commit -m fixed-fork done :) > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
