Does anybody other than me us the "fossil ui /" command - with the extra "/" argument? How many of the readers of this Forum even know about that variant of "ui"?

Did you know that you can "fossil ui" to any remote machine to which you have SSH access? For example, I have headless RaspberryPI-4 on my local network named "pi4". If I want to see all of the Fossil repositories on that machine, I can type: "fossil ui pi4:/". How many users of Fossil know that you can do that? How many readers of this message wish they had known about this feature before?

Did you know that if you have a big uncommitted edit in a local Fossil checkout and you would like test your changes on another machine prior to check-in (perhaps a different architecture or OS or perhaps just a beefier machine that will run the tests faster than your desktop) that you replicate all of your uncommitted changes into a checkout on the remote machine using a command like: "fossil patch push REMOTE:/path/to/checkout". I use this feature all the time to test SQLite changes on Mac and Windows prior to checking those change in. My linux desktop is an older machine (Intel i7-4770K running Ubuntu 16.04) and so I usually push my edits to a newer and much, much faster server for testing prior to check-in using this same mechanism. I don't know how I was able to get any work done before I had the "fossil patch" command. But I wonder how many other people know about it and/or actually use it?

Maybe its just me, but I think these (and lots of other things in Fossil) are really cool features that are unappreciated and often even unknown to most users. What can I do to better publicize them? Or, should I just let Fossil be Fossil and not worry about it - let users find the features for themselves?

I think people would appreciate it. It reminds me of the examples in the sed man page.

Looks like you already have a name for the wiki page too...

That page (with a slightly different name) has been up for years: https://fossil-scm.org/home/doc/trunk/www/hints.wiki. It is linked from the home page, but I don't think many people visit that link.

Looks buried in a wall of links. Man pages have the advantage of conventions so you know you can scroll to the bottom to find examples if there are some.

Maybe move the hints link into Primary Documents, indented under Quick Start? Seems kind of related to me -- after a quick start, some cookbook examples might be nice...

fossil ui /

TIL…

you can "fossil ui" to any remote machine to which you have SSH access

I knew that was possible, but I'm struggling to come up with a good example of something you need that for which won't work against the local clone.

/doc/ckout/file previews to check uncommitted doc changes that have to be made on the remote for some reason, I guess?

I use [the patch push] feature all the time to test SQLite changes on Mac and Windows prior to checking those change in.

I use it with my hobby writing projects since those are stored and managed by a combination of Calibre and Fossil. Each tool does many things the other does not, and I need the union of several of these. I store the MD source text in Fossil, which I "open" over the top of the Calibre doc tree, which holds other files not checked into Fossil, such as the EPUB outputs I have Calibre generate from that MD source text.

The thing is, while Fossil is distributed, Calibre remains stubbornly centralized, so whenever I want to do an operation on the Calibre library, I either have to go back to the central server somehow — move my carcass, VNC, SSH, whatever — and work there temporarily, or…

Fossil to the rescue! With patch push, I can update the clone of the Fossil-managed parts of my library to where I'm working, push it to the remote, then VNC/SSH into the remote to do the minimal amount of Calibre-side work needed, check the changes in there, then return to working at my local machine.

It's somewhat awkward, but that's not Fossil's fault. Short of turning Calibre's library into a distributed DBMS I can run on all my systems to give a single unified view of the library, this is as good as it gets.

During a writing session, I might push changes through this loop a dozen times or more.

As an answer your original question, I think learning new ways of using existing tools is always valuable. Is there a "Tips and Tricks" or "Daily Use" wiki page or embedded documentation?

I didn't know about fossil ui / however I can't seem to get it to work. I run fossil under cygwin. My web-browser setting is cygstart which is on my path.

If I run fossil ui in an open checkout, I get:

Listening for HTTP requests on TCP port 8080

and the page shows up in my default browser instance.

fossil settings web-browser in the same directory gives me:

web-browser          (local)  cygstart

If I run fossil ui / in the same directory I get:

Listening for HTTP requests on TCP port 8080
------------- 2024-04-25 16:31:41 UTC ------------
warning: cannot start browser

Thinking it was a local vs. global setting issue, I cd'ed out of the checkout/working directory and ran:

% fossil settings web-browser
web-browser          (global) cygstart

so the browser is correctly defined at global level.

If I run fossil ui / in the non-checkout directory I get the same (can't start browser) output as running it in a checkout directory.

Since the error message indicates fossil started a web server, I navigated to http://localhost:8080/ and I see a listing of repos (hidden and visible), but nothing on the page is a hyperlink unlike (IIRC) the repolist parameter.

Am I describing the web page correctly and any ideas about the browser issue?

All bets are off for cygwin. Should work for you on Win11, Mac, Linux, BSD, etc. If you want to suggest patches to get that feature working on cygwin, they will be thoughtfully considered. :-)

Can you give me a hint where to look? Is there a debugging flag I can turn on that tells me what files it's opening, what it is executing and where it gets the setting?

Since it works when I am in the checkout directory, the basic spawning of a browser works. If it didn't work at all, I'd agree with your bet.

When running as fossil ui / where does the web-browser setting come from? I assume ~/.fossil? Should there be a difference in PATH between the two cases?

For those following along at home, I strace'ed the fossil ui / command and surprisingly it looks like it's groveling C:\Users\username\AppData\Local\_fossil which IIUC is the .fossil equivalent on windows. Dumping that with sqlite3 select * from global_config shows web-browser|cygstart and it also shows the 8 repos it lists in the repolist page.

So this hybrid windows/unix thingy is odd. Hmm, looks like I am using a fossil from 2022 (2.19) as well. Guess I should use a new build first.

where does the web-browser setting come from

It's a setting, normally undefined.

Whether it's needed varies by platform.

You're probably falling blindly into the _WIN32 case, where the setting is the only option, never even trying the Linuxy fallbacks in the third case. Extending the ifdef with "&& !defined(__CYGWIN__)" may be all you need. It depends on whether you have browsers in your PATH on Cygwin, or if xdg-open works as it does on Linux.

It might be better to add a fourth case to that function that calls cygstart on the URL instead. That behaves much like "open" on macOS or "xdg-open" on Linux.

Is there a debugging flag I can turn on that tells me what files it's opening

No, but there is strace for Cygwin.

Ok, looks like there was bug in the 2019 version of fossil. This is fossil version 2.24 [70cae0a964] 2023-12-14 17:24:49 UTC works fine.

The page that is opened doesn't have any links on it, but I assume it's supposed to be that way.

Sorry for the noise.

Or could be Fossil compiled for Cygwin vs native windows fossil running inside a Cygwin shell?

I don’t know, I didn’t use Cygwin since a long time.

Good idea. I checked and the binary I was using is linked to the cygwin dll. So it's a cygwin binary.

With the new build, I haven't checked to see if I am still accessing the windows global fossil db. Maybe I'll check for grins over the weekend.

Also Warren thanks for the pointers. I know about strace, that's how I found the fossil binary was using the _fossil database.

Thank you for this message. Actually it's been the exact same for SQlite also.

I have been spending hours; or days making lists of interesting features just because when you use good tools you want to know them better.

I must admit the website even being close to complete is not (structurally) made as you perhaps intended for. (i.e I think it does not serve even half of its purpose)

But I won't say any more than that.

Wish you success.

Please rebuild your local "fossil" binary using the check-in 362a7b7c9de817d1 or later and report back whether or not this resolves your issue.

I compiled Fossil and tested it afterwards, and the issue has been resolved.

What can I do to better publicize them?

I remember one of my first editors was jEdit and it used to have tons of useful features, shortcuts, tricks, ... It is written in Java and used to take quite some time to start. However, slow startup time was well compensated by displaying a useful tip on every start. Usually it was formulated something like the following:

"Did you know, that by pressing ... you can achieve .... "

usually followed by a link to the help page with more detailed explanation.

I remember that I've learned many useful shortcuts and tips just by reading those tips while waiting for editor to start.

Perhaps, it would be possible to mix a few links to some random tips among forum threads. Those tips can lead user to related documentation page, and they may be formatted differently to be easily recognized as not being forum threads. That way each time we look at the page with the latest threads, we might also spot some hidden gem like the one you've described above. Also in the email notifications a tip or two could be added to the list of the latest forum threads. Instead of a rather general title like "Stupid Fossil Tricks", each trick should have a one line description. For example for the tip described above, the teaser line could be:

"Did you know: By using fossil ui <url>, one can browse repositories located on a remote machine"

Rarely used features, tend to be forgotten. By putting some reminders in a place frequently visited/read, might help users to learn and remember all those features so that they can use them when the need arises. Sometimes it is enough just to be aware that some feature exists and when the need is present, one can lookup and search the documentation or even ask for help here. But, when you haven't any idea that some feature is even possible, chances are that you're not going to use it even if you really need it.

Maybe the "Did you know: tooltip can be put in the Web UI, and enabled in the "/admin" tab of such interface. In my own case, I found those reminders and tips useful and I would enable them by default, to help with features discovery. Maybe some HTML trick can showcase them for few seconds on localthost once the fossil ui command is launched.

Cheers,

Great idea!

Does anybody other than me us the "fossil ui /" command - with the extra "/" argument? How many of the readers of this Forum even know about that variant of "ui"?

I generally use it this way, and have done ever since I wrote my one-liner fossilserve command back in October 2022. This was an update from the previous solution I wrote two months before, which involved a fossil on a port for every single fossil I wanted to host... which gradually got unwieldy due to the number of fossils I wanted to look at with a browser. So I switched to the much simpler form above.

As for most of the other tips mentioned above, no I did not know them, nor was I (mostly) ever going to use them. However, it's nice to know that the

fossil ui machine:/

will pick up fossils on the other machine. I'll have to remember that one. For that hint in particular, how would I customize it so it refers to using a different user on that machine than my currently-logged user in "this" machine? Would that require tinkering with ~/.ssh/config to add the relevant host as an alias? I show a sanitized and condensed version of my ssh config setup here:

 26 Host first
 27   RhostsAuthentication no
 28   PasswordAuthentication yes
 29   IdentityFile ~/.ssh/id_***
 30   User playme
 31   Compression yes
 32   Port 22
 33   Cipher blowfish-cbc
 34   EscapeChar ~
 35
 36 Host Firsty
 37   HostName first
 38   RhostsAuthentication no
 39   PasswordAuthentication yes
 40   IdentityFile ~/.ssh/id_***
 41   User bark
 42   Compression yes
 43   Port 22
 44   Cipher blowfish-cbc
 45   EscapeChar ~
 46

Regards, brickviking
(Post 30)

... are really cool features that are unappreciated and often even unknown to most users.

I guess the flip side is how to prod users to let you know what things they like, outside of bug reports and the occasional bit of general praise, there's probably not much said.

Maybe periodic (eg, yearly) polls/surveys, or dare i mention it, opt in telemetry like firefox does.

Anyway, i've found patch very useful too.

I have many old machines: desktops, netbooks, raspberry pis; and one of my pieces of software is a media system which needs to account for differences on raspberry pis vs everything else.

Patch lets me test and try things out easily.

One very very slight negative for me is the output. It usually shows me status-style "Up to date" and i often find myself doing a diff to make sure changes have applied. I think that phrase is a trigger that makes me think that things are pristine and unchanged.

I reckon some sort of diffstat would cure me of that, but i'll happily keep using patch even if the output stays the same. :)

Actually, i've been thinking of an idea to use patch combined with unversioned files to snapshot work-in-progress changes.

Say at the end of the day, there's a bunch of changes that aren't ready to commit, instead of committing to a temp branch or leaving as is:

• patch to a file: fossil patch create WIP.patch
• add that file unversioned: fossil uv add WIP.patch
• sync to repo server: fossil uv sync

That way, whatever machine i find myself on the next day, i can pull down and apply the WIP patch file.

At the least, it acts as a backup too.