What fate for the "fossil get" command?
(1) By Richard Hipp (drh) on 2026-01-05 13:49:30 [link] [source]
About 2.5 months ago, there was a discussion on this forum that resulted in a new experimental command being added:
Is that command useful? Should it be retained? Should we added it to the change log for the 2.28 release? Or is the "get" command just more clutter in the command namespace?
(2) By Andy Bradford (andybradford) on 2026-01-05 17:02:16 in reply to 1 [link] [source]
It would be nice if the OP on the related thread were to chime in. I think the command could be useful in some scenarios, but I'm having a hard time finding a use for it in any of my daily work. If you hadn't brought it up, I might have forgotten about it until... One day I may have remembered the feature and found a fit for it... who knows.
(3) By anonymous on 2026-01-06 20:43:23 in reply to 1 [link] [source]
I came here looking for something similar to this. I assume the ?VERSION? is a sha hash correct? I see this as being useful, but would really like to be able to say "fossil get URL ?DATE?" where I get what was current on that date (in repository time. no timezone weirdness or anything like that).
I want this so that I can have a project in one repo pull files another repo as a dependency in a reproducible way, without having to add special tags to the source repo. I can make shas work, but an "as of" date would be ideal.
(4) By Richard Hipp (drh) on 2026-01-06 20:49:35 in reply to 3 [link] [source]
VERSION can take many different formats. (See https://fossil-scm.org/home/doc/trunk/www/checkin_names.wiki for details.) Among those forms is "BRANCH:TIMESTAMP" where BRANCH is some branch name (like "trunk") and TIMESTAMP is some ISO 8601 time in UTC. This selects the first check-in from BRANCH that occurs on or after TIMESTAMP. You can omit the "BRANCH:" prefix and then it gets the first check-in from any branch on or after TIMESTAMP.
So, yes, "fossil get URL DATE" should work.
(5) By anonymous on 2026-01-06 20:54:52 in reply to 4 [link] [source]
That's excellent, Thank you. I would like to see this command officially added.
(6) By Andy Bradford (andybradford) on 2026-01-08 15:10:24 in reply to 3 [link] [source]
You can certainly use DATE as a VERSION, however, you may not always get what you expect. For example, if there are 4 branches---"trunk", "bugfix", "stable", and "feature"---that all have commits on 2026-01-08, which version of the code will you get when you run the following? fossil get URL 2026-01-08 Well, the answer to this is that it depends on which branch has the nearest commit matching that date. That could be "trunk", it could be "bugfix", it could be "feature", or it could even be "stable" which has very few commits and is "older" code because it doesn't have any new features. Clearly the more precise your date, the more likely it is that you'll get what you want, unless of course you don't care what it is that you get, just that it's some version of the code. If you're trying to pull in dependencies, it's probably better to do so based upon an actual branch name or some other more reliable tag.
(7) By Richard Hipp (drh) on 2026-01-08 15:24:31 in reply to 6 [link] [source]
The command:
fossil get URL trunk:2025-01-08
gets you the newest check-in on the trunk branch that is from the date 2025-01-08 (UTC). In other words, the last trunk check-in for that day.
Add "THH:MM:SS" for a more precise time if you need greater accuracy.
fossil get https://sqlite.org/src trunk:2025-01-07T12:00
Gets you the last trunk check-in that occurred on or before 2025-01-07T12:00:00Z, which happens to be the check-in at 2025-01-07T11:54:43.
(8) By Mike Swanson (chungy) on 2026-01-13 10:07:01 in reply to 1 [source]
One nitpick from testing the feature: time stamps aren't preserved in the extracted files. If I use --sqlar trunk.sqlar followed by sqlite3 trunk.sqlar -Ax, the time stamps are preserved as I'd expect.
As for the utility of the command, it definitely seems fairly weird to have the fossil binary, yet not want to clone the repository. Zip, Tarball, and SQL Archive links are provided in the web interface of any server running Fossil remotely, and I imagine that's infinitely more useful to any possible "want latest code, but don't want to clone the repository" use case. All you need is a web browser and a utility to extract the archive.
(9) By Andy Bradford (andybradford) on 2026-01-13 15:34:21 in reply to 8 [link] [source]
> All you need is a web browser and a utility to extract the archive. I was pretty much on your side for the "utility" (no pun intended) of the new command until Richard mentioned that it can also be used to "fetch" SSH-only repositories. In the original thread, I argued that CLI tools like ftp(1), wget, curl, etc., could all be used to automate the downloading of a specific version of a repository without a browser and without needing to clone, however, that doesn't account for SSH repositories. Now with "fossil get", one can do, for example: fossil get ssh://anonfsl@fossil.bradfords.org//fossil --dest fossil-tip But, as you ask, if a person already has the fossil command, why not just clone? Only those who use the "fossil get" command will know, I suppose.
(10) By Mike Swanson (chungy) on 2026-01-13 20:22:45 in reply to 9 [link] [source]
I was pretty much on your side for the "utility" (no pun intended) of the new command until Richard mentioned that it can also be used to "fetch" SSH-only repositories.
It's really hard for me to even imagine that being a realistic use-case here for fossil get. I can understand the desire to bring ssh-only repositories to feature parity with one served over HTTP, but I just think it's a solution in search of a problem.
If I really stretch my thinking, maybe if the repository is 100GB but the tip is only 10MB of files, it could save time, but what Fossil repositories are anywhere close to being large enough for this feature to save such bandwidth? The largest I have is sqlite.fossil currently sitting at 268 MiB. This becomes a bad example precisely because it is publicly accessible over the web. You can just download a tarball or zip from the download page and go from there, no fossil binary required.
PS: I just noticed I used the word "utility" twice in my first message in two different contexts and definitions. Probably should have avoided that. :-)
(11.1) By Andy Bradford (andybradford) on 2026-01-13 22:20:39 edited from 11.0 in reply to 10 [link] [source]
> I can understand the desire to bring ssh-only repositories to feature > parity with one served over HTTP I don't think it was the impetus for the feature, certainly. > but what Fossil repositories are anywhere close to being large enough > for this feature to save such bandwidth? I used to have a clone of the NetBSD src Fossil repository. It took 2 weeks to clone using an experimental version of Fossil which allowed resuming if the clone operation was interrupted for some reason. Here are some stats: $ time fossil dbstat -R netbsd-src.fossil project-name: NetBSD src repository-size: 50,270,945,280 bytes Some may not wish to clone the entire 50GB Fossil repository just to get the latest code. Yes, this is not the typical Fossil size, so you may still be right that it's a solution in search of a problem, however, it is still a tool.
(12) By Andy Bradford (andybradford) on 2026-01-13 22:24:55 in reply to 10 [link] [source]
> It's really hard for me to even imagine that being a realistic > use-case here for fossil get Also, there's one other use case that may be overlooked here... One of Fossil's purposes is that it is intended to be a test bed for SQLite features. In this respect, the "fossil get --sqlar" option meets the criteria I think.
(13) By Mike Swanson (chungy) on 2026-01-14 00:27:02 in reply to 12 [link] [source]
Is that fundamentally different than the existing fossil sqlar command?
(14) By Thomas Hess (luziferius) on 2026-01-19 09:06:12 in reply to 1 [link] [source]
I have no personal use for that yet. But I do envision a potentially good use-case: That is use by automated CI/CD or build tools.
The systems I see, like those automated GitHub runners, do spin up a blank-slate VM or container, clone the repository, then build from there, output logs and build artifacts, and then discard the system.
The usefulness of fossil get in that case depends a bit on the command's efficiency. Is a shallow tree copy created by fossil get cheaper than a full clone? If so, using get would reduce load on both sides.
(15) By Richard Hipp (drh) on 2026-01-19 10:53:05 in reply to 14 [link] [source]
Is a shallow tree copy created by fossil get cheaper than a full clone?
Yes. Particularly so if the web-cache is enabled using the cache init command.
On the other hand, "fossil get" is not as efficient as running "fossil up" on an existing clone.
(16) By Daniel Dumitriu (danield) on 2026-01-19 11:24:40 in reply to 15 [link] [source]
The efficiency bit is probably only of secondary relevance for CI, which is where I also see its best use-case. Thus I would keep it.
(17) By Thomas Hess (luziferius) on 2026-01-19 12:29:01 in reply to 15 [link] [source]
Then get is a good fit for this.
When I've read through some CI task logs, I saw git clone invocations. These runners would do a fresh clone on a clean slate VM each time they are invoked, which renders the gains by update moot.