Fossil Forum

Awesome Fossil
Login

Awesome Fossil

Awesome Fossil

(1) By Eric Wikman (ericwikman) on 2022-10-26 14:28:10 [link] [source]

Is there a curated list of awesome[0] extensions/community features/projects based on Fossil?

I'm new to Fossil. So far the only additional tool I'm using is koog1000's VS Code plugin which is great. From searching the web and the forums I also found fnc, Fuel, and SnailFossil.

I'm currently only using Fossil for note keeping and I am wanting to tighten up my workflow and automate it a bit. I'm going to be building a shell script similar to gumblex's inotifycommit.sh that auto-commits markdown files and adds new markdown files once it has been at least one minute since the last save/add and attempt to put some form of auto-generated commit message. I'm also going to work on having my iphone sync on a timed basis so that I have a local copy of my notes should I be without cell service.

BTW - I think the fileedit feature is being under-advertised. It is a great feature! I get the sense that there is concern that people might shoot their own foot with it and that might be why it isn't very front and center or more obvious that it exists and how to turn it on. Now that it is over a year old, maybe the fileedit-glob should default to .md,.txt for new projects.

[0] https://github.com/sindresorhus/awesome

(2) By Stephan Beal (stephan) on 2022-10-26 15:26:27 in reply to 1 [link] [source]

BTW - I think the fileedit feature is being under-advertised. It is a great feature! I get the sense that there is concern that people might shoot their own foot with it and that might be why it isn't very front and center or more obvious that it exists and how to turn it on.

(Disclaimer: i wrote /fileedit)

In practice it's really just not terribly useful for most of fossil's target audience: software developers. We always have a local checkout handy and always have emacs handy, and a web-based editing option is a pale shadow by comparison. It was initially implemented primarily so that i could make "drive-by edits" in doc pages from my tablet from bed :). In practice, though, seeing typos in my docs from a tablet from bed almost always causes me to get out of bed and get on the computer... where there's a local checkout and a full-featured text editor, making /fileedit unnecessary except in rare cases.

That said, i could see non-developers (e.g. writers) getting more use out of it, but that's not fossil's primary target audience.

Now that it is over a year old, maybe the fileedit-glob should default to .md,.txt for new projects.

Having that feature turned off by default was never really about whether /fileedit was stable enough for it, but about sanity and project security (against potential, as-yet-undiscovered bugs which might permit malicious edits of a repo). For example, it's really easy to create inadvertent forks with /fileedit and it "should not" be used willy-nilly by folks who don't understand the ramifications of doing so (in particular because they'll need a local checkout to resolve merges of all such forks, as we have never had a web interface for doing so (nor any compelling drive to create one, as we generally don't like to check anything in which we haven't at least tried to compile yet, and a web-based interface to merging makes testing merges before checking them in impossible)).

/fileedit seems likely to always remain an opt-in-only feature.

(6) By Eric Wikman (ericwikman) on 2022-10-27 20:09:53 in reply to 2 [link] [source]

This all makes sense.

I am a software developer, but am using my personal notes as my first foray into using Fossil. I used Microsoft Visual SourceSafe in the late 90's, moved to SVN at some point, and to Git about a decade ago.

For the past decade I've come to fossil-scm.org about every other year and read half the website and tell myself the next project I start I'll use fossil instead of git, but don't end up doing it.

Taking the plunge with my notes is a path with little resistance since I don't need to convince other developers to use fossil instead of git, and it'll give me time to get use to fossil and make mistakes to learn from before I move development projects over.

(12) By matt w. (maphew) on 2022-12-28 20:54:28 in reply to 6 [link] [source]

For the past decade I've come to fossil-scm.org about every other year and read half the website and tell myself the next project I start I'll use fossil instead of git, but don't end up doing it.

This is so me! Thanks for this thread. My hold up is less about Fossil instead of Git, though that's definitely in the mix, and more about fossil's markdown syntax and th1 not being aligned closely enough to my non-software-developer desired use case (website cms).

To me Fossil is a golden exemplar of how to properly do a batteries included, network centric, multi-user, multi-device/platform, sqlite as an application format program. I'm truly mystified why there aren't legions emulating the example across many problem domains. I guess it's just hard.

(3) By Stephan Beal (stephan) on 2022-10-26 15:29:49 in reply to 1 [link] [source]

I'm going to be building a shell script similar to gumblex's inotifycommit.sh that auto-commits markdown files and adds new markdown files once it has been at least one minute since the last save/add and attempt to put some form of auto-generated commit message.

BTW, regarding automation you might also want to look at:

https://fossil.wanderinghorse.net/r/libfossil

It has a number of CLI tools which might be useful to you. One of them in particular sounds appropriate for you:

https://fossil.wanderinghorse.net/r/libfossil/file/f-apps/f-ciwoco.c

can create checkins directly into a repository without requiring a checkout.

(7) By Eric Wikman (ericwikman) on 2022-10-27 20:11:08 in reply to 3 [link] [source]

This is great!

I saw mention of libfossil when I was reading the forum about fnc, but didn't understand that it had CLI tools or that it was 3rd party.

(9) By Stephan Beal (stephan) on 2022-10-27 20:37:28 in reply to 7 [link] [source]

I saw mention of libfossil when I was reading the forum about fnc, but didn't understand that it had CLI tools or that it was 3rd party.

"Semi-third-party" might be a better description. It's developed primarily by me, and i've been a contributor to fossil since 2008. It's not officially part of the fossil project but libfossil follows fossil's developments closely and it's kept up to date with core-level changes in fossil. The core-most SCM features are taken directly from fossil and, with Richard's blessing, simply refactored to support a library-style interface.

(4.1) By Warren Young (wyoung) on 2022-10-26 19:07:28 edited from 4.0 in reply to 1 [source]

Is there a curated list

Yes.

It's incomplete. For one, the first customization I most commonly apply on setting up a new repo is to apply the Fossil Modern skin from my Inskinerator project, then apply Prism.js highlighting to the relevant files for that repo.

To see an example of this in action, say:

  $ fossil clone https://tangentsoft.com/fossil x.fossil
  $ fossil uv sync -R x.fossil
  $ fossil ui x.fossil

Now visit a URL like /file/container/Makefile and observe that it's nicely syntax-highlit. (Or, visit the live web demo.)

Unless your list of file types matches mine, though, this will require hand-hacking on your part since I don't ship a bloated Prism configuration that works for every possible file type. You might not even have Makefiles in your repo, or if you do, you might have other file types that need highlighting atop that. If you scroll down in the forum thread I linked to above, you can see the details of how to accomplish these customizations.

Having done all of this, the fossil init --template feature may come in handy for creating more repos configured the same way, avoiding the need to redo the customization work.

For a more robust demo showing the improved Markdown formatting of my Modern skin plus Prism.js, see here. Clone that repo without pulling unversioned artifacts to strip the Prism element out, and append "?skin=default" to the default URL to strip the Modern skin customizations out to see the difference.

(8) By Eric Wikman (ericwikman) on 2022-10-27 20:36:34 in reply to 4.1 [link] [source]

That is what I was looking for. I don't know how I would have found that though, it doesn't seem to be linked from the main site that I found. Perhaps there is a section of the website I haven't found yet.

Your skin and syntax highlighting look great. I did see this article: https://fossil-scm.org/home/doc/fileedit-ajaxify/www/fileedit-page.md

that shows how to integrate highlight.js to the fileedit feature. I found it linked from a forum post about fileedit that I found when I was searching to see if anyone had tried to integrate Ace, Monaco, or CodeMirror with Fossil.

Most online git hosting websites have an editor based on one of those libraries, but I get Stephan's point.

Thanks for linking to your forum post on prism, makes sense to me. I definitely like your idea about "Integrating Fossil with..."

(13) By matt w. (maphew) on 2022-12-28 21:14:02 in reply to 4.1 [link] [source]

Is there a curated list

Yes. It's incomplete.

Two other examples that I'm aware of:

There's no longer an extant public version of PDQ that I'm aware of but I did make some headway with it last year. I got stuck because a) I'm 90% Windows and although PDQ was up and running happily in WSL I couldn't communicate with it reliably across WSL's virtual network; and b) problems with SSL certs and necessary prompts not always being shown. (I had similar problems with virgin fossil in my networks so it wasn't PDQ's fault.)

(5) By Gour (gour) on 2022-10-26 20:32:17 in reply to 1 [link] [source]

I'm currently only using Fossil for note keeping and I am wanting to tighten up my workflow and automate it a bit.

I'm looking into some note-taking application for Zettelkasten method, so can you give us some more details about your usage of Fossil?

Sincerely,
Gour

(10) By Eric Wikman (ericwikman) on 2022-10-27 21:45:12 in reply to 5 [link] [source]

I'm not a very organized person, so probably not the best to discuss. I migrated from Evernote to Google Keep (was planning on migrating to SimpleNote instead of Google Keep but Google Keep was already on my phone and chromebook so I took the lazy route). My style has been similar to what Google recommended for gmail organization, don't do it and use search to find things.

These were my rough requirements for my new note taking to migrate out of Google Keep:

  • clear text only (markdown support for viewing)
  • can be tracked with a VCS
  • prefer to not use a specific program unless that program stores everything in clear text that is easy to open in other programs (I don't want to be locked in or have a hard time migrating someday in the future)
  • can organize using folders
  • can link from one note to another
  • can search globally
  • notes kept in sync between my laptop and my phone and available via the web when necessary

This is more of a braindump then a well written explanation:

A wiki seemed to make the most sense for me. I could have gone with a single user wiki system, or a program that specializes in markdown text files, but I wanted to use VS Code as my editor.

Essentially I'm just using the file part of fossil as my wiki, not the wiki feature built-in with Fossil. I wouldn't be able to achieve the above goals with the wiki system in Fossil, but the file browser in Fossil's UI still formats markdown and follows links to other notes.

VS Code has a great plugin with Fossil. VS Code can do more things with Markdown than I need, but I'm using it minimally.

I'm using a folder structure that is very rough right now. I'm not taking the time to actually migrate my old notes, but creating all new notes with this, and anytime I want to edit an old note then I migrate it over. I'm creating folders just in time, so I haven't thought out a structure, but it will evolve, and I like refactoring the folder structure as it grows.

I'm using Prettier to cleanup my markdown files every time I save them.

I really like looking at the diff's of my notes before I do a commit.

I setup VS Code to auto-save my notes after 15 minutes when changed in case I walk away from the computer before saving.

I'm going to write a shell script to auto-commit after a certain amount of time if I haven't manually committed. I prefer to manually commit most of the time, but if I walkaway from the keyboard, I want it to eventually commit so that it flows through to my other devices.

I sync Fossil on chiselapp as my source of truth that other devices update with.

The mobile experience will need some more thought and work. But right now I use iSH to give me a full POSIX environment with Fossil installed and using scripts to keep things in sync and expose my notes to iOS. If I have internet, then I might be more likely to use chiselapp. If no Internet then I use Runestone, although I was tempted to use a text editor on iSH but realized that was silly.

There are many plugins for VS Code that could improve things, but I want to keep as simple as possible. Plus if I decide to switch to VIM (or even Midnight Commander) from VS Code I want to make sure that everything will still work fine.

Although this goes against the above, I do want to play with using tickets and the forum as part of my workflow for ephemeral things. Tickets for a todo list, forum to flush out ideas and thoughts.

(11) By anonymous on 2022-11-08 21:58:51 in reply to 10 [link] [source]

It's not fossil-specific but emacs' org-roam (it's designed to give you a roam research-like experience for note taking) makes taking and publishing networked notes really easy. While I stopped checking my notes in, it is easy to do so. Finally, I just export my notes and publish them online.

Relevant note: org-roam uses sqlite as its local datastore.