How to avoid creating local repo?

You can't. Aside from the sync protocol itself, fossil works exclusively with local copies of repositories.

Edit: an alternative is to use the project's /zip page to download a snapshot of one specific version, but that has to be repeated for each new version. It would likely be more space- and bandwidth-efficient, long-term, to clone the repository.

clone the repository

Obtaining all versions and not the last one only. Correct?

Obtaining all versions and not the last one only. Correct?

Correct. We would like for fossil to support "shallow clones" (storing only the branches or versions it strictly needs to for local work) but doing so would require a significant rework, as its internals very much depend on having complete access to the history.

fossil tarball as git archive?

its internals very much depend on having complete access to the history

I understand but don’t really need any versioning function. Just the code. And the next time, if ever, again.

use the project's /zip page to download a snapshot

Unfortunately project doesn’t appear to offer pre-made zip or tarball. At least I could not find it in the files list or hamburger button.

Unfortunately project doesn’t appear to offer pre-made zip or tarball.

/zip is a page fossil provides which downloads a zip of a specific version of your choice.

/zip is a page fossil provides

Nice. Thanks. Alternative to fossil tarball?

Alternative to fossil tarball?

They're identical except that one emits a tar.gz and one emits a zip.

There’s also fossil zip which I assume is called by the ui. Edit: /tarball also.

Why www.fossil-scm.com instead of fossil-scm.org in those URLs? Firefox complains about the certificate because it isn't valid for that host.

I have not attempted to check if www.fossil-scm.com is a genuine alias that has been left off a (recently created) certificate, or it is in fact a rogue site of some sort. Generally I go for confusion rather than conspiracy, but one day I'll be wrong.

Maybe it's your cache, but (at least) the current certificate has www.fossil-scm.org as alternative name:

Not Before: Oct 4 01:09:37 2025 GMT

Not After : Jan 2 01:09:36 2026 GMT

Subject: CN=a1.sqlite.org

X509v3 Subject Alternative Name: [...] DNS:www.fossil-scm.org [...]

I have not attempted to check if www.fossil-scm.com is a genuine alias that has been left off a (recently created) certificate

It is genuine but (A) yes, it seems to have been left out of the cert list and (B) Google seems to prefer serving "www."-prefixed domains for fossil-scm and sqlite.org.

$ dig fossil-scm.com
...
fossil-scm.com.		276	IN	A	194.195.208.62

$ dig fossil-scm.org
...
fossil-scm.org.		0	IN	A	194.195.208.62

At least I could not find [zip or tarball] in the ... hamburger button.

There is now an experimental change on the main server that incorporates a "Tarballs and Zips" link in the hamburger menu. This takes one to a page with buttons to click for various tarballs and zips.

As you know now, it is possible to download a tarball/zip for any check-in. The new /tarlist page only shows a handful of check-ins. The choice of check-ins can be configured by the administrator. I have the Fossil source code repository configured to show just the latest trunk check-in plus the two most recent release check-ins. (Experts: The suggested-tarlist setting is "1 trunk 2 release".)

Over at the SQLite source repository I have the /tarlist configured to show the latest trunk check-in and the seven most recent releases. (Experts: setting is "1 trunk 7 release".)

WuMing2: You are new to Fossil, I think. That makes your opinion in this matter more important. Does this feature make it easier for newcomers to find where to download tarballs and zips?

Does this feature make it easier for newcomers to find where to download tarballs and zips?

I think so. Menu option is fairly higher up to be easily noticed. Available options of two formats for most branches and releases are very generous.

git checkout —> local copy w/o repo

This one is not correct ;-)

Like Fossil, Git is a DVCS, where 'D' stands for "distributed". This model assumes any "clone" of a repository is normally self-containing and self-sufficient, with the ability of them to exchange commits and other data being, actually, not strictly required.

The git checkout command populates the so-called "work tree" with the state of the files and directories as recorded in a commit, but the repository is still there — either in the ".git" subdirectory or elsewhere (for complex cases). You cannot git checkout from a Git server, so to speak.

On the othe hand, Git supports so-called "shallow-clones", where a cloning may bring in just a mimimum set of data so that the local repository (to which the cloning is done) contains no history or a small subset of it.

This one is not correct

Thanks for remarking my mistake. Found reference on stackoverflow but clearly I misinterpreted it. Didn’t try it anyway.

Suppose there was a command that would reach out and download a tarball or similar from a remote repository then unpack it locally, all in one step. What would that command be called?

Example:

fossil eligere https://fossil-scm.org/home trunk

This command would contact the server named by the URL, extract the latest "trunk" check-in, send just that one check-in over the wire perhaps as a tarball, then unpack it locally.

It seems like this could be useful, no? And not too difficult to implement. I dare say I might have an implementation in the tree within a day or two if y'all can suggest a sensible name to use for the placeholder "eligere" shown in the example above.

Maybe this isn't a separate command but just an option to the "checkout" command?

fossil checkout trunk --extract-from https://fossil-scm.org/home

my 2c:

• I would think this should not be delegated to be an option of checkout. the latter should remain a "repository-related" action in my view

• if made a new command and the "semantic collision" with what +git fetch+ or +hg fetch+ does is considered irrelevant +fetch+ would be fine. or +grap+ (but then it sounds like +grep+) or +snatch+. something like that?

• although this thread might indicate that such a command could be useful for some users, I personally think it is essentially sufficient that one can download tarballs from the remote repo via web ui already. but OTOH, having the functionality available via CLI is of course nice, too.

I agree on points 1 and 3.

'Eligere' is nice but probably not very domain appropiate... 'Download' sounds too generic. Folding it into zip is appealing but might make it too obscure.

'Snapshot'?

Maybe: 'fossil download https://fossil-scm.org/home trunk' ? Or just 'get'?

It seems like this could be useful, no? And not too difficult to implement.

FWIW: +1.

... if y'all can suggest a sensible name to use for the placeholder "eligere" shown in the example above.

(Certainly Daniel already knew this, but: https://en.wiktionary.org/wiki/eligo#Latin)

If it's an arg to the zip/tarball commands it doesn't necessarily need a new name:

fossil zip https://fossil-scm.org/home/trunk/my-copy.zip

Edit: or...

fossil zip --unpack --remote https://fossil-scm.org/home/trunk/my-copy.zip

to both download and unpack.

When you do the command

fossil eligere https://fossil-scm.org/home trunk

(for some substitution of the placeholder "eligere") does it put all of the files in the working directory, or does it create a subdirectory named "fossil-scm.org" or "trunk" and unpack everything into that subdirectory?

Perhaps there is a "--subdir NAME" option that overrides the subdirectory name, and if you want to expand into the working directory you could say "--subdir ."? Maybe --subdir is called --into or --dest instead?

I took it that that should bring a disconnected snapshot, so we'd rather quit/warn if within a working directory. Or maybe allow it into any subdir, as long as empty?

Isn't pointing somebody to the zip/tar download URL even easier than explaining them another new Fossil command?

And people who are not interested in the project history wouldn't even have to get the Fossil binary, first.

And people who are not interested in the project history wouldn't even have to get the Fossil binary, first.

That's definitely a compelling counter-argument.

BTW: That's how I've been using the source code of Git-based projects for years, just download the zip without ever installing the Git binaries.

yes, definitely. as said, I also feel an easy way to download via the web-UI is sufficient. but...: for people unacquainted with the fossil web-UI it sure is not self-explanatory how to find a way to download the tarball or zip archive (assuming default config of the web-UI), no? so maybe a default "Download" menu entry and some added logic to select which checkin to use for the download (current trunk or possibly something else) could help.

what I also have noted is, that the name given to the tarball is constructed for as "project+name-hash.tar.gz" while the root dir of tarred tree is called "project name" (with verbatim blank). so the used project name is used verbatim in the root dir name rather than replacing any blanks by "+" or "" or similiar. I would argue for doing the same sort of blank substitution everywhere (and would think "" more common than "+"?). blanks in file names remain a pain etc...

That works fine if the server is publicly accessible on the web, but not for "ssh:"-style private repositories. The new "fossil get" command works for both.

The new "fossil get" command also works for "file:"-style URLs. That does really provide any advantage over "fossil open" for manually typed commands. But in a script, where the URL might be anything, the "fossil get" command works in all cases, whereas the ftp/wget/curl approach only works for "http:"- and "https:"-style URLs.

It doesn't seem to work with the anonfsl Fossil server that I setup:

Perhaps due to the preexisting code at zip.c:1036-1038. I think I need to record it to use ZIP Archives instead of SQL archives.

There are other bugs too, that I'm working on.

Maybe, as a tiny QOL improvement for non-SCM users downloading the zip archives, the --name option could be exposed to the zip/tarball web UI pages. But this may have security implications (?name=/bin), drive AI bots even crazier, and require changes to the Fossil web cache.

Your question seems to relate an existing repository.

Technically for the sake of sharing a single fossil repo with multiple work directories "avoid creating local repo" LiteFS can be the answer, but you need to have access to the server https://github.com/superfly/litefs

Disclaimer, I never worked with LiteFS before, my first tought was to patch fossil with a sqlite over network wrapper that I worked with years ago, but LiteFS seems to be simpler.

Now available on the get-command branch is a new command "get".

fossil get URL ?VERSION? ?--dest DIRECTORY?

The URL can be an "http:", "https:", "ssh:", or "file:". VERSION defaults to "trunk" but can be any valid check-in name. The check-out is unpacked into DIRECTORY. You can do "--dest ." to unpack into your local directory. There are other options as well. Run "fossil help get" for details.

I'm open to renaming this command to something other than "get".

Post suggestions are comments as follow-ups to this message. If there are no serious objects, I will merge to trunk.

How It Works

The client sends an HTTP request to URL using the same mechanism as it would for doing a "sync" or "clone". But the request is of the form:

/sqlar?name=NAME&r=VERSION

Where NAME and VERSION are determined by the command-line inputs. This request should return an SQL archive as a Blob. If the --sqlar option is present, then the SQL archive is simply stored in the file named by --sqlar. If the --sqlar option is omitted, then the SQL archive is queried using SQL and individual files are written to disk.

No comment/view on the command itself, just a "just in case" question: does it, or does it need to, sit behind – or interact with – the recent anti-robot-attack defenses?

No. Because the robots are sending HTTP requests. We are talking about a new command on the command-line here. Robots do not have access to the command-line.

Robots can send the /sqlar HTTP requests that the new command uses. But that is already dealt with.

Robots do not have access to the command-line.

Somewhere in the distance i just heard a cry of "challenge accepted!"

My humble point of view. With a reference to /zip and /tarball in the hamburger button menu I would not have started this discussion. Existing zip and tarball commands as alternatives for who has the binary installed already (assuming -R accepting a remote repo URI). In short I would not change anything.

Kinda too late. I've already implemented the "fossil get" command. It seems to be working well.

On the other hand, adding a new "/archives" webpage that gives you a menu of possible tarball and ZIP downloads, and then adding that page to the hamburger menu, might also be useful.

The code for the "fossil get" command is now on trunk. If y'all decide that we should delete that command, well enough. The exercise of adding the new command brought a number of infrastructure bugs and omissions to my attention which have now been fixed. The "fossil get" command can be removed simply be deleting the "get_cmd()" function and its header comment from the "checkout.c" source file and recompiling.

If anything I would have reused the export command (now deprecated) with appropriate options. Reminiscent of svn export. But more commands are better be avoided if possible.

I did happen to think of "fossil pick ...." to pick a revision from the codebase, pack it up in zip/sqlar, send it over the wire, and unpack at the local end. "fossil get" implies getting the whole thing, at least to me.

(Edit) ... or perhaps "fossil latest". My other choice of "fossil grab" doesn't suggest grabbing the latest (or tip) code. And "pick" implies that I can choose any revision, which is already supported by fossil.

Regards, RTDoc brickviking
(Post 68)