On Thu, Apr 16, 2015 at 1:22 PM, Ron W <ronw.m...@gmail.com> wrote: > On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland <mattrwell...@gmail.com> > wrote: > >> Since these are effectively forks that have been resolved by merging is >> it possible to detect them as such and not report them? >> > > I think they probably could be reported as "merged forks", but I'm not > sure that adds value. What if someone assumes that whomever merged the > fork's content had simply forgotten to either close the fork or otherwise > "resolve" it? >
I think merging a fork resolves then it and it is no longer a fork. Only open forks represent potentially orphaned changes. Maybe we need better terminology. I don't call a merged fork a fork. The word "fork" implies divergence to me (consistent with the usage in another thread about project forks). If xemacs and emacs projects merge together they are no longer forked. I suppose they were previously forked but if I'm an emacs aficionado I don't care about a fork in the past that has been merged. By my working definition of the word "fork" reporting a fork that was merged back to the origin branch is a false error. > Absent a comment or other explicit indicator of intent, any fork, merged > or not, should be carefully reviewed and its status explicitly denoted. > > > _______________________________________________ > 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
