Fossil Forum

I would just build it, if I were you.

As you are already a fossil user, it is literally about 4 commands away, and will take you less than 5 minutes.

You could even ask one of those AI things what to type into your computer if you wanted.

What system are you running on?

I speak this as an entirely novice level computer user who works in healthcare as the day job.

But that's definitely what I would do.

(Supplementary: is there an ongoing reason why the JSON API should not be available in the standard binaries by default?)

That's my fault. Richard told me, way back then (2011? 12?) that it could be enabled if it had complete test coverage, and that's never been added beyond (IIRC) very basic fuzzing support. Patches to improve that would be welcomed, but...

1. The JSON API has never been well-received/widely used. There's a small handful of people who use it, and i used to use it to host a custom wiki front-end which rendered all pages client-side using the Google Code Wiki format, but haven't done that since finally giving in to Markdown. i.e. its general utility is in question.

2. That API predates SQLite's JSON support. It "would be cool" to see it completely rearchitected/reimplemented on top of SQLite's JSON support, and greatly simplified (the interface API was way over-specififed in the name of flexibility, but that level of detail has never proven necessary for me in other JSON APIs), the caveats being that (A) i've not got the energy for it and (B) nobody else has yet volunteered.

I would just build it, if I were you.

As you are already a fossil user, it is literally about 4 commands away, and will take you less than 5 minutes.

You could even ask one of those AI things what to type into your computer if you wanted.

You mean, like ... go fishing, instead of trying to get someone to give me a fish? Not a bad idea, and it may come to that.

Thanks for that insight, Stephan. I was interested to read the 2011 origins of this API in the docs. :)

I wonder, too, whether this might be me having an XY problem? What I want to be able to do is fetch, via URL, information about a file in "machine readable" form. There is finfo, of course, but it returns HTML, and scraping that would be no fun.

This is what the JSON API provides, of course. If there was another way of achieving that without enabling the JSON API, that would help to know.

Thanks again!

There is finfo, of course, but it returns HTML, and scraping that would be no fun.

It's /finfo that returns HTML; fossil finfo returns human-formatted console output.

Regardless, neither format is guaranteed stable, so even if parsing it was a task you considered fun, it would be inadvisable for software meant to work long-term.

A subset of the CLI commands do return output meant to be machine-parsed at need, mainly by eliding excess formatting. A good example of this is the new "fossil whatis -h NAME" option for getting the hash of a given name; it returns nothing but the hash, allowing direct capture without parsing.

Beyond that, I'd need to know which specific information you are wanting about these files to suggest alternatives to the JSON API.

The policy of not enabling it until it is thoroughly tested is a good one. Parsers are notorious sources of security vulnerabilities.

It's /finfo that returns HTML; fossil finfo returns human-formatted console output.

Yes, stupidly I had the slash originally, but I deleted it as the "help" I linked to was finfo (sans slash). :/

But also, yes,

specific information you are wanting about these files to suggest alternatives to the JSON API.

What I'm trying to get is simply the timestamp (date/time, whichever) of the file's last check-in. The HTML from this type of link...

http://example.com/repo/finfo?name=path/to/file&n=1

...does include that information, buried in the HTML (e.g. ...timeline?c=2025-08-02+17:13:16&u=...) which could be pulled out with (in my case) PHP tools.

I played with using /raw with timeline, but that didn't get me very far!

Hopefully that's a clearer picture of what I'm trying to achieve, though. AFAIK, the JSON API gives much more: uuid, timestamp, user, comment, size, and state for the complete history of the file (a lot of "finfo"!). That is a bit of "sledgehammer" for this little "nut", but it works.

This sounds like stat(2) to me, so if it were me, I'd just do a "fossil update --setmtime" and then start scripting against the checkout, which will end up in calls to stat(2).

I'd just do a "fossil update --setmtime"

Don't forget fossil touch.

go fishing

Teaching a man to fish is soon to be a thing of the past if "AI" has anything to do with it.

At any rate, what are you trying to accomplish?

Tantalizing suggestions, but I'm not clear how to make these work in a URL?

Something close would be: http://fossil.example.com/repo/timeline.rss?n=1 BUT that is (as far as I can see) "file-agnostic" (I don't see any "file" information in the output). If one could restrict the /timeline.rss output to a single file, that would do it. This kind of thing, in other words:

http://fossil.example.com/repo/timeline.rss?file=path/to/file&n=1

But unfortunately that doesn't seem to work. (I tried ?path=, too, but that doesn't work.) OR if /finfo.rss was available on the analogy of timeline.rss... That kind of thing.

The timeline command with a -p|--path PATH argument and a custom -F|--format?

And -n|--limit N!

And -q|--quiet!

That's very close to what I posted above in #11, but this also does not work:

http://fossil.example.com/repo/timeline?path=path/to/file&n=1

(with or without .rss): it always returns the latest commit, no matter what file/path is provided. So close and yet so far!

Yes, the timeline CLI command requires a local repository (but not necessarily an open check-out, it accepts -R REPO) and doesn't work with URLs.

So, I bit the bullet (rather than the fish), and built fossil on my local Ubuntu 24.04 machine. And ... IT WORKS! :)

It took me slightly more than "less than 5 minutes", by the time I'd read the docs, tried to understand what I was doing, installed the bits recommended for "debian" environments, and waited for the build to run. More like ~15mins, which isn't too shabby. And it works nicely on my local machine!

For some reason, the /json bit that works nicely locally does NOT work on a remote VM that I scp'ed this fossil binary to (it's also running 24.04), so I'm not sure what that's about.

Still, I've learned a lot on this exercise, and that's worth something, too!

Yup 😉 Z

It took me slightly more than "less than 5 minutes"

Fair comment, but it won't next time, of course.

For some reason, the /json bit that works nicely locally does NOT work on a remote VM that I scp'ed this fossil binary to (it's also running 24.04), so I'm not sure what that's about.

Then it's picking up a different copy of fossil.

If one could restrict the /timeline.rss output to a single file

You mean like this:

https://fossil-scm.org/home/timeline.rss?name=VERSION&ci=tip&n=1

Of course you have to parse RSS data, but there are likely tools around for that. Maybe sed, for example:

curl -s 'https://fossil-scm.org/home/timeline.rss?name=VERSION&ci=tip&n=1' \ | sed -n -e '//,/<\/item>/ { s/([^<]*)<\/pubDate>/\1/p; }'

That would do it, but /timeline.rss has no ci parameter, so it gets ignored. One can only give a tag with tag, but at the moment I am unsure why this does not return what I'd expect (the equivalent of "2022-06-17 10:57:00"):

That would do it, but /timeline.rss has no ci parameter

Oops, yes, I don't know how that got in there. That also explains why I got the same results whether I used ci=tip or ci=trunk. I think tag does work though.

Was VERSION updated in the version-cmd-describe branch?

Please try instead:

curl -s 'https://fossil-scm.org/home/timeline.rss?name=VERSION&tag=trunk&n=1' \ | sed -n -e '//,/<\/item>/ { s/([^<]*)<\/pubDate>/\1/p; }'

And if you want to see the last 10 timestamps along with their hashes:

curl -s 'https://fossil-scm.org/home/timeline.rss?name=VERSION&tag=trunk&n=10' \ | sed -n -e ':start;//,/<\/item>/ { s/([^<])<\/pubDate>/\1/;t fix;s/.\/info\/([^<])<\/guid>/ \1/;t end;n;b start;:fix;h;n;b start;:end;H;x;s/([^\n])\n(.*)/\2\1/;p; }'

Which should produce the following output:

   17f88fe064ddd1652d2d588586ab54439cb02f061b31bcbdeea0d4b648d5b44c      Thu, 12 Mar 2026 12:49:59 +0000
   c8fcc9714ee99c3449af810f9db250943dc52d09ef843488b20aada993a51376      Tue, 30 Sep 2025 18:13:34 +0000
   8b24838e95ef7830a01e8e35c0f6557b40d38f5f761782a8784c5e4b2ba304f1      Fri, 2 May 2025 10:30:57 +0000
   66899f89c6d3012dc2c863474caa4adc8cc4265771e86825eaaa08e50ed2f7e9      Wed, 6 Nov 2024 13:21:03 +0000
   929f36ae3c559584da81bed0fa086fcdf865ab260ac1843299d680ff37e8dfd9      Tue, 23 Apr 2024 14:33:55 +0000
   9b642594730ca1a340e538d530dded6dacd1575efe9fa7c8682af9ba8599cd18      Fri, 10 Nov 2023 14:41:36 +0000
   9f857c2d03a12180f2e85d2f718ffc1ffa9ecf9f2b004cd317fb9040caf611e3      Thu, 1 Jun 2023 17:18:46 +0000
   e13f7ca4a775fda402d08dfe8823df628604c94cfabce2bd44f6ba8ba97de8e3      Sat, 25 Feb 2023 22:11:55 +0000
   8dcee008378a64a966908824b7dd95fb07c0b54bc1f1e4c8b7b76e59a3d11045      Thu, 17 Nov 2022 07:45:41 +0000
   a3bdee629d124fa55b7f4eb080117c9449e566d0638dc92d0d52737918fbcb33      Thu, 21 Jul 2022 16:11:41 +0000

Please try instead: . . .

That is very nifty! But crucial (for my interest, anyway :/) is the lack any file association or information.

That's why I was day-dreaming about getting RSS for /finfo/ which is, I take it, the closest Fossil gets to something like (pseudo-command): timeline?file=path/to/file.

Fascinating to see these possibilities, though!

The association of the file is in the URL. That's what the name= query parameter represents. So results are filtered by the filename that you provide in that query parameter.

Also, didn't you say that your goal was to get the timestamp of when the file was modified? I think that's precisely what I have demonstrated.

If you can show that the results include output that is not associated with the name= query parameter, that would be a bug in my opinion.

So in your example, you would want:

http://fossil.example.com/repo/timeline.rss?name=path/to/file&n=1&tag=trunk

The association of the file is in the URL. That's what the name= query parameter represents. So results are filtered by the filename that you provide in that query parameter.

Doh! Apologies! I am such a numpty. I saw what sed was extracting, but not the raw RSS for context.

That is pretty brilliant! :) Thanks so much for investing time in my conundrum. That looks like an excellent solution!

Then it's picking up a different copy of fossil.

Thanks for pointing this out; I had it in mind it might have had something to do with security.

But you were right. :) At some point it dawned on me why my newly json-enabled fossil wasn't being found. I corrected that, and it's now working. 🎉 Z

With that help provided, I've got a super work-around for vanilla fossil (without json enabled). Given I use this with PHP tools (mentioned up in 7.1 in this thread), this is fast and efficient way of getting the last-modified date for a file:

$url = 'http://fossil.example.com/repo/timeline.rss?name=path/to/file&tag=trunk&n=1';
$xml = simplexml_load_file($url);
$date = $xml->channel->item->pubDate;

Then $date can be tweaked, or the pubDate can simply be echo'ed directly. Works a treat! So grateful for all the help here. I've learned a lot.

Then $date can be tweaked, or the pubDate can simply be echo'ed directly.

With one warning borne of many years of PHP madness of my own: don't echo it without escaping it first (i've forgotten how that's done in PHP). A malicious server could put anything in that date, and simply echoing it may emit a script tag, for example.

Thanks for the warning! That's one of the reasons I used $date — in my case, I strip it down to (e.g.) 2 Aug 2025 17:13 before echo. That's another benefit of the RSS approach, I suppose: you get a standardized format for the pubDate field. Z

That's another benefit of the RSS approach, I suppose: you get a standardized format for the pubDate field.

My point is, though, that a malicious server/modified copy of fossil can put anything in that field. There's no parsing logic going on which will prohibit a SCRIPT tag as a value.

There's a small handful of people who use it

Raising hand.

I use it in application logic, to implement an update checker. My desktop app queries /json/tag/list/, and then extracts tags conforming to the semantic versioning spec to determine if new versions are available.

Using the API was the solution with the least manual burden. This solution doesn't require HTML parsing, sifting through a lot of unrelated entries in the RSS feed, or manually maintaining an (un-)versioned file containing the latest version.