On Fri, Nov 24, 2017 at 11:55 AM, Richard Hipp <d...@sqlite.org> wrote: > > On 11/24/17, Johan Kuuse <jo...@kuu.se> wrote: > > I agree on that we would give up Fossil semantics. > > I have no intent to "give up" or change the semantics of Fossil, and I > see no reason why enabling Fossil to push and pull from Git > repositories would require this.
I think 'push' and 'pull' seems fair enough. But what about 'rebase' and 'submodule'? To what level should the Fossil-NG client support Git features not present in Fossil? If supported, wouldn't there be a risk of confusion when the user wants to 'rebase'? Even if commands such as 'pull' and 'pull' could be used transparently, the user would have to take in consideration what kind of backend is in use (Git or Fossil) before using 'rebase'. If not supported, wouldn't there be a risk of users just sticking to 'git rebase' instead? Sorry for not grasping the advantages about this idea. > > Both Fossil 2.x and Fossil-NG will be able to read and write the same > Fossil repos, as long as you do not run use Fossil-NG features. After > you "rebuild" and start using Fossil-NG specific features, legacy > Fossil-2.x clients might no longer work with that particular repo. > This is the same situation that came up in the Fossil-1.37 to > Fossil-2.0 transition. That transition went smoothly and I expect the > transition to Fossil-NG to be just as smooth. Not a big deal, but will Fossil-NG repos be readable (the same way as Fossil repos are) by sqlite3 from the command line? (Currently I have a few scripts using that feature.) Best Regards, Johan _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
