I want a repository that uses a name other than "trunk" for the primary branch. I know, I could just create the other branch and use it, but I would rather that "trunk" was never visible at all. However there doesn't seem to be any way to create a new repository with anything other than "trunk".

Any suggestions?

Not sure if there's a way not to have trunk branch created at all on init.

However once the repo has been inited and opened, you may rename trunk into whatever name you prefer using 'fossil amend --branch' command. Also there's a Fossil setting main-branch that should be changed accordingly, by default it's set to trunk

For example,

 mkdir newrepo
 cd newrepo
 fossil init ../newrepo.fossil
 fossil open ../newrepo.fossil
 fossil timeline                      ## shows an initial commit to 'trunk'
 fossil amend current --branch thebranch
 fossil timeline                      ## trunk has been renamed to 'thebranch'
 fossil branch                        ## shows only `thebranch`
 fossil set main-branch thebranch
 fossil close
 cd ..
 rm -rf newrepo newrepo.fossil

The 'fossil branch' output is

* thebranch

Thanks, that seems to work - except for the Edit in the timeline caused by the amend, which I would really rather not have.

If renaming "trunk" (via the ui, or the amend command), or creating your check-ins as branches originating from "trunk", are not viable options, here's how to create a completely empty repository:

• md empty-dir (or mkdir on Linux)
• fossil reconstruct empty.fossil empty-dir
• rd empty-dir (or rmdir on Linux)

Now you can open the repository, add files, and commit using the --branch option to indicate the name of the default branch.

Also make sure to adapt the main-branch and the download-tag settings (the latter is accessible through the /setup_config web ui).

The init command used to create completely empty repositories, but this was changed for some reason, likely because some functionality of Fossil does not expect completely empty repositories, or repositories lacking "trunk", respectively. So this technique may be risky and should be used with caution.

(I'm using this procedure to create completely empty repositories as a base to create mirrors of git repositories using the import command, and everything seems to work fine.)

From the Fossil sources it looks like we use "trunk" in many places verbatim instead of through db_get("main-branch","trunk").

For example, in db.c:db_initial-setup() -- it's just one place, there're quite a few other places.

If we'd stick to consistently referencing trunk from the main-branch setting (why not?), then a new repo could be constructed with 'fossil init --template' from a template repo which has its main-branch already set to something else than "trunk".

Maybe even add a new option, something like `'fossil init --main-branch'" to make this even simpler.

The initial valid manifest could be generated with any valid branch name other than "trunk". It's just that currently it's hard-coded to "trunk" .

...I've been wondering several times if the --empty option could be reenabled?

If we adopt a consistent use of db_get("main-branch", "trunk") and implement something like 'fossil init --main-branch', there should be no need for the removed --empty option.

If we adopt a consistent use of db_get("main-branch", "trunk") and implement something like 'fossil init --main-branch', there should be no need for the removed --empty option.

I like that idea, and also, while I'm being picky, make the main branch have no background colour (like "trunk" currently), whatever its name.

Never though of trying reconstruct on a empty directory!

Followed by

fossil commit --branch mybranch --allow-empty --comment "initial empty checkin"

Seems to be a good solution at the moment.

I have a correction to a statement of mine:

It's not always granted that the repository has a valid manifest as RID 1 after importing a git repository into a completely empty Fossil repository (i.e. "reconstructed" from an empty directory). [0]

But this is the same when creating a new Fossil repository from a git repository following the method documented in Fossil: Import And Export.

git fast-export --all | fossil import --git new-repo.fossil

With the above command, I end up with Fossil repositories containing a .gitignore file artifact as rid:1, for example.

So the import command does not seem to enforce the rid:1→manifest policy. That's why I think the policy could probably be dropped, and the --empty option could be reenabled.

[0] My quirky method to "reconstruct" empty repositories is because I have a script to periodically update my git→Fossil mirrors by means of incremental imports. The script clones the repository from the server, performs the incremental git import locally (due to the server lacking the git infrastructure), and synchronizes the result back to the server, maintaining the import/export marks as unversioned files. The workflow is simpler if I can create empty repositories on the server, as there's no need to handle any special case for new mirrors.

Some background trivia regarding RID 1...

Fossil historically creates an initial empty checkin which, because it's the first blob added to the db, gets the first ID from the blob.rid sequence. That initial ID is 1. While working on libfossil i found that there was nothing in fossil's design which required this initial commit, but that several places in fossil assumed that the blob table had at least one entry (it assert()ed that in a couple places, IIRC). Jan Nijtmans (IIRC) patched those places in fossil so that it did not require an initial commit and, IIRC, it was he who added the "empty" option to the "init" command. i don't know exactly when or why that was removed, but it was, and fossil still creates an empty initial commit.

The reason a repo does not necessarily get RID 1 when doing a reconstruct or git import is because RID 1 gets assigned to whatever blob is added first. When doing a non-empty commit, all blobs for that commit must be added to the DB before the commit itself (which is also a blob) can be added. Thus the first blob (regardless of its type) will get RID 1, and the RID of the first commit will be equal to the number of blobs in that commit, plus 1.

That said, the RID values are strictly internal and can vary between two clones of the same repository. Their values reveal what order each blob was added to each clone, but they are not guaranteed to be stable and must never be relied upon for anything useful outside of fossil's own internals.

PS: using reconstruct to generate an empty repo db is a really cool trick! i will certain use that at some point.

Thanks for the interesting explanations.

Creating an empty repository database also works with init, then shunning the initial commit, and rebuilding the repository. But this is more work, and it seems that this can only be achieved over the web ui, that's why I resorted to the reconstruct command.

By the way: the handy sqldiff utility can be used to compare the differences between two Fossil repository database files. From my experiments, it seems that there's no significant differences between a regularly initialized Fossil repository, and one reconstructed from an empty directory with a custom initial (empty) check-in. The differences arise from columns representing modification time stamps, mostly from the config and user tables, and not from metadata tables.