On Nov 21, 2017, at 1:24 PM, Ron W <[email protected]> wrote: > > But, a "universal VCS adaptor" won't really be universal, so tool developers > will still end up supporting git, Hg and maybe SVN, so why would a tool > developer support Fossil-NG?
Tool developers will ignore Fossil-NG to the same extent that they ignore Fossil today. The advantage is purely on the Fossil side: by allowing a tool to send us checkins via Git, they don’t *need* to support Fossil. If the user on the command line then says “fossil ui”, they should get a sane picture of all the commits their tool has been making via Git. If someone then clones the Fossil repository via its Git interface, they get a local Git checkout version of the remote Fossil repo, and I wish them all the enjoyment they may squeeze from that bitter lemon. :) > As for inter-operating with other VCSs, why is any given Fossil user using > Fossil instead of one of the others? Because the project’s creators and primary maintainers may not all agree on “best,” much less what the peanut gallery wants. I’d like to stop caring about what everyone else wants when I choose the project VCS. If they want to go use Git against my Fossil repository, I don’t care as long as the checkins come in well-formed, properly-commented, and on the right branch. I almost didn’t start using Fossil at all because of that concern. I *almost* switched from svn to git, purely for the network effect advantages. How many others have been making the same decision, but the other direction, and how many more will make the decision that way in the future? What if we could say, “Use Fossil for your own reasons, but know that we’ve got all the interop you could wish for if you need to use some other tool that isn’t Fossil-OG compatible.” That’s powerful stuff. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

