On Thu, Apr 16, 2015 at 1:27 PM, Ron W <ronw.m...@gmail.com> wrote: > On Thu, Apr 16, 2015 at 2:41 PM, Andy Bradford <amb-fos...@bradfords.org> > wrote: > >> This document contains what Fossil considers a fork: >> >> https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki > > > Yes. And the _connotation_ of the term "fork" within the Fossil community > is unintended/accidental commit to a parent commit with other child commits. > > My point is that Fossil uses the term "fork" differently from many other > many other open source projects. Examples: "Devuan" is a fork of Debian, > "Inkscape" is a fork of "Sodapodi", etc. Or, how Github uses it to mean a > "contributor's clone". >
Some thoughts: If a unique term is required, how about calling an undesirable branch a twig. ;) More seriously, the Wikipedia article on forking is probably worth a read: http://en.wikipedia.org/wiki/Fork_(software_development) I would claim that github is the odd man out here, having appropriated a term that historically meant something undesirable and changing it into an intended desirable part of the software development process. Mind you, forking in a github sense doesn't have to mean "project branch with future pull requests" though obviously that's how they intend it. A github fork is really just a heavyweight branch, and until github was launched in 2008 (assuming their fork functionality was an original concept introduced at launch) no one in the world used "fork" in this sense. Looking at the list of DVCS projects on Wikipedia, it means every "notable" DVCS was introduced prior to that usage (except for Veracity, which is apparently / arguably dead anyway). I don't think github's success devolves on anyone else to change their terminology any more than I think git's success means that everyone should adopt their confusing hodge podge mass of commands & options. In fact, from this point of view, github redefining terminology is unsurprising given how I feel about git's use of terminology in places. Given the traditional meaning of fork (an undesirable branch of development that, if allowed to remain, limits future development options in some way), I don't see that there is a real problem continuing to use the term fork. Introducing a new non-obvious term just so there is distinct separation between "fossil forks" and "github forks" seems to only complicate the understanding of fossil. Note that "undesirable branch of development" could apply to how fossil uses fork, or how github might use fork in the case that the original project never pulls anything back so the two projects diverge, or how BSDs or emacs/xemacs forked deliberately. Accidental head or accidental branch don't seem to apply if for no other reason a fork *can* be deliberate. That's not the norm but --allow-fork does exist as an option for those cases when fossil can detect a fork will happen but to allow it anyway. I suspect most people don't type --allow-fork accidentally (when they type it at all). :) So, if we *must* have a unique term, I'd vote for twig as I've never heard it used in a dvcs context and can't find such a reference via Google. Mind you, if we started using twig there is nothing to stop github (or others) from coming along and appropriating the terminology, so we could wind up right back in this position seven years down the road. Or we just continue to document what we mean when we use the term fork (perhaps providing the extra text "two leaves on the same branch" or some such when a fork warning is generated) and continue to provide the existing tools to merge or rename. -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
