3 ms·
It's been a while, but I roughly recall: The formatting in the wiki was unusual; it was difficult to access wiki/doc/issues outside of the builtin webserver (fo
by fundamental 10y ago
It's been a while, but I roughly recall: The formatting in the wiki was unusual; it was difficult to access wiki/doc/issues outside of the builtin webserver (for tickets I ended up building a TUI as a workaround https://github.com/fundamental/fs-tickets https://github.com/fundamental/fs-tickets (the original fossil repo is sitting around somewhere)); there was no 'fossil grep'; the lack of a staging area was annoying when sorting through exploratory changes (git add -p and vim's git-fugitive options make the staging area hugely useful); attaching files to issues/wiki/etc was difficult; setting up a remote which could be pushed/pulled from (with multiple machines) was difficult; and I recall the username + password combo failing in a way that I never diagnosed.
Overall I'd say fossil has its share of warts and it currently doesn't justify the contribution barrier it introduces with enough in return.
- rkeene2 10y agoMany of these issues have likely been resolved. Wiki supports the wiki format, markdown, and HTML now. There is now a "fossil search" command for full-text search (including artifacts, if enabled). I've never had a username/password failure so no idea what that could be. For tickets, icomment is probably the solution you want but it's not very intuitive. git add -p doesn't require a staging area per se, and I could see that being added as part of the commit process... but usually I like to test my changes a little bit before committing (e.g., does this even compile) and I can't do that on a partial commit.