Rather than comparing Fossil to Git, I compare it to Github, the Git hosting service I'm sure you're all aware of. They've come a long way extending Git to make it easier to use and add the integrated issue tracking/wiki that Fossil has that Git alone doesn't have. Github additionally has some pretty nice looking Windows/Mac GUI desktop apps for managing your local repositories, that automatically set up SSH keys, etc., and make the barrier to entry for Git trivial for those users (let's face it, if you're a linux user, you should already know how to generate SSH keys and do command line stuff, so I guess they didn't feel it was necessary to provide a GUI so far).
The key difference between Github and Fossil, in my opinion, is that Github is not open source and is quite expensive to use. I still use Fossil on many personal projects, mostly because I run out of "private" repositories on Github and am reluctant to increase my plan due to the monthly bill. Github is a bit more shiny as a web application (I would hope so, given the money they've got going in that they can spend on design/feature aspects). Also, there's the fact that you typically provide your own hosting for Fossil (although I know of the Chisel project--looks like that is coming along as well; nice work James.), and the "forking" social aspect they sell with. One thing I like about Github that I wish Fossil had were email notifications about things like commits and issues created/updated. I know this was discussed years ago, and how it's difficult to set up because you don't know which machine had the changes committed and who has already sent emails out. But I imagine most people interested in this feature use Fossil with a server hosting the "main" repository, so there should be a flag or something you can send to fossil that would broadcast issue updates/code commits, based on some configuration for an email server to send through. As to the latest emails: The rebase commands come with many warnings about how you shouldn't rewrite history except in your local copy, and people have mixed opinions about that: http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.htmlThe fact of the matter, though, is you can choose whether you want to use that feature of git or not; you're certainly not forced to use it. I somewhat prefer the autosyncing honest way that Fossil uses, but I can see why some people would prefer to have one commit to look through while merging changes in from someone, for example, which is the main use-case for rebase, in my opinion. Anyway, I don't mean to cause a heated discussion. Just throwing out some more noise to this conversation, as one who uses both Fossil and Git on a regular basis. Wes On Fri, Sep 14, 2012 at 12:00 PM, Jacek Cała <jacek.c...@gmail.com> wrote: > 2012/9/14 Bill Burdick <bill.burd...@gmail.com>: > > > > Sure, you could have named, alternate timelines and just choose which > one to > > make the default, each timeline forming a namespace for its branches and > > tags and timelines could inherit from other timelines. That way you > could > > have rabasing without losing history. > > > > Hmmm... being pragmatic, who would like to have many timelines in the > same project? IMHO that would make things quite complicated or at > least unclear. Whereas the 'private' commit tags (which I mentioned > above) would make things easier I believe; easier to implement and > easier to use. > > Cheers, > Jacek > _______________________________________________ > 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
