I'm in the process of converting all my repos over to fossil from git,
and would like to know if there's a way to prevent fossil from
creating the initial empty check-in that gets created with every
fossil init command.

I did some searching and saw and tried fossil init --empty,
which seems to have been deprecated.

I also tried fossil init repo --date-override now but that
didn't prevent the check-in; though I'm not certain that was the
appropriate way to use the flag if the intent is to prevent the
check-in.

I also read I could purge the initial empty check-in but fossil
replied with cannot purge the current checkout so I've exhausted
the few options I managed to find and would like to know if and how
it can be done. Thanks.

... and would like to know if and how it can be done.

There's not, to the best of my knowledge, a straightforward way to do it since the removal of the init --empty option. You can create an empty one using this roundabout approach:

mkdir foo
fossil reconstruct foo.fsl foo
rmdir foo

but it's possible that not all commands will work on such a repo. Fossil has historically always assumed that a repo has been "seeded" with at least one commit, and some commands will fail if that's not the case.

open will work, though, as will commit (just tried it).

Thanks, Stephan. I appreciate the suggestion.

Out of interest, is there any mailing list discussion surrounding the
removal of the --empty flag that I could read? And, would there
be any interest in accepting a patch that reimplemented something
similar that achieves the same purpose?

I'll run a search on the mailing list; thanks.

It would be good to ascertain why a user-initiated "initial commit"
doesn't satisfy the seed effect of this enforced initial empty
check-in to see if it's something I could finesse. It's not a complete
deal breaker in converting over from git—I can always carry a local
patch—but the piquancy of the --empty flag removal and why
an initial commit of actual files doesn't suffice has made my
curiosity get the better of me.

What's the reason for not having the initial empty check out? It's bening yet useful in setting the repo up in a functional state.

Are you mirroring from git or just exporting? If mirroring, then indeed this needs to be a feature (in fossil's git mirroring), so that the sets of hashes are identical between git and fossil.

If you just exporting, then what's a big deal? All hashes are going to be newly generated in the fossil repo.

FYI there's also 'fossil open --empty' forumpost/0141acfcbc

BTW, finding any old forum posts here is nothing trivial, in some cases nearly impossible...

It's redundant if you're only going to make an initial commit with
actual content; so why can't the substantive commit set the "repo
up in a functional state" as well as serve the purpose of committing
files?

But, yes, initially these will be mirrored from git to facilitate the
transition. Although now, as I said, I'm interested as to why it's
even needed—surely the first user-initiated commit can serve the
same purpose as this initial empty check-in. And, if not, I am
interested to find out why.

Thanks, Andy. That's very helpful.

At a cursory glance, it appears the primary objection to
fossil init --empty is backwards compatibility breakage due to
the assumption that rid=1 is type=ci; however, what's
stopping the user-initiated "initial commit" that contains files from
having type=ci?

I've literally just scanned the thread in that link and have yet to peruse
the mailing list thread that it references so please excuse any naivety
in my question. However, I don't think this is an irredeemable problem
for want of a better term. I'll give the entire history a thorough read
and take it into consideration when looking at the source code for
any potential fix. Thanks again.

what's stopping the user-initiated "initial commit" that contains files from having type=ci?

When you create a commit, the files for the commit are necessarily added to the db before the checkin record, and thus one of the new files would get rid 1. That's unavoidable.

Thanks for that insight, Stephan.

My first thought, are we stuck with the check insisting on it being
precisely rid=1? That is, it can't be a range of rows/records?

Also, am I incorrect in assuming that for those of us not running
version <= 1.27, there's no loss of functionality if rid=1 isn't
type=ci?

My first thought, are we stuck with the check insisting on it being precisely rid=1? That is, it can't be a range of rows/records?

Any range would need to be arbitrarily chosen and then accounted for in code, neither of which is appealing. By and large, the fossil internals don't care what's in the blob table (home of the RIDs), nor should they need to. The historical assumption that RID 1 was a checkin, and always existed, indeed simplified some code, and thus it became a relied-upon assumption for a while. The code base has since matured to the point where that simplification/assumption is no longer terribly useful.

Also, am I incorrect in assuming that for those of us not running version <= 1.27, there's no loss of functionality if rid=1 isn't type=ci?

"Probably," but that's not a guaranty. While i'm not personally aware of any code which currently requires/assumes that RID 1 is a checkin, or which outright crashes if there is not at least one checkin, there's certainly a possibility that such code either still exists or will be added.

Similarly, some code explicitly requires having an existing commit. e.g. the infrastructure for the new fileedit page requires it, and cannot be used on a purely empty repo. It doesn't care what RID that checkin has, though.

Rather than an arbitrary range, can it be of any int value?

Or changing the other side of the comparison, are we stuck with
type=ci; that is, can it be of type x || y || z?

I'm on holidays from next Thursday so would be happy to invest
some time if it's at all viable and something that would be considered.

I don't think I'd be part of an insignificant minority that would
welcome the added option, but if it's a definite "no" than I'll only
worry about making it work with current and future versions and
keep a local patch.

I'm on holidays from next Thursday so would be happy to invest some time if it's at all viable and something that would be considered.

See /forumpost/ef9b840b9f for why i suspect that such a patch would not be accepted.

I did see that yesterday; I'm hopeful that it wasn't the feature he
didn't want—but the breakage/incompatibility with older versions.
And, if so, the time or opportunity cost wasn't conducive to
implementing a fix.

Given that we're a few years post its removal, I wonder if the
compatibility issue isn't as consequential—or if more help might
make the opportunity cost more favourable—would it warrant
reconsideration?

Given that we're a few years post its removal, I wonder if the compatibility issue isn't as consequential—or if more help might make the opportunity cost more favourable—would it warrant reconsideration?

That's a fair question... which i cannot answer :/. FWIW, to me it always seemed like a reasonable/desirable feature, if for no other reason than it allows non-English-speaking users to have an initial commit message in their preferred language.

That's something I hadn't even considered—but is definitely yet
another benefit it would bring.

I also feel like it would remove another barrier to git users and,
although I'm sure fossil's mandate isn't to convert users of other
SCMs, as someone who wants to use fossil vice git—the more
fossil users, the more likely I'll be able to use fossil in different
environments that would otherwise dictate I use git.

And to be completely candid, I think that would produce a net
positive for development in general; it's a simpler, more cohesive
and consistent model that would reduce friction and improve
dynamics that can only benefit everyone involved.

It's redundant if you're only going to make an initial commit with actual content;

We could (in theory) extend the "fossil init" command so that it accepts a list of files/directories to use as initial content and then prompts you for the check-in comment, I suppose.

I think the reason I reverted the earlier --empty change is that there are many places in the code that assume that the repository contains at least one check-in. But it does not have to have one empty check-in as far as I recall.

None of this has deep philosophical implications. I reverted --empty because it didn't work and was causing bugs, not because I am morally opposed to its existence.

But the deeper question is "Why?" Why go though all the work of implementing, testing, and supported such a feature? Is it really such a terrible thing to have a separate initial empty check-in? What problems does the initial empty check-in cause?

That would actually be a perfectly fine solution; more often than not
I'm creating a repo with multiple files ready to commit and am quite
literally issuing fossil add . && fossil ci -m 'Initial commit'
immediately after fossil init repo.fossil.

I also imagine it would be much less work, and I'm happy to contribute.

Primarily, it's cleaner: an empty commit is redundant and I can't
envisage any scenario that plan for a perpetually empty repository
so even in the case someone initialises a repo with no source
files ready to commit, there could be a readme or license or some
other generic documentation, which would only comprise a later commit,
that could slate this first commit.

But there are practical reasons, too, such as mirroring or, as Stephan
remarked, enabling ESL users to create an initial commit in their native
language. I'm sure there are multiple use cases that don't affect me
but that might be of use to others. From the git perspective, given its
ubiquity, it would provide a more consistent experience for those
converting and possibly increase retention rates in that demographic.

Something as simple as fossil init repo.fossil --add /repo/*.{h,c} --msg 'Initial commit'
would be great.

Well, I was the one removing - one-by-one - all places in the code where the assumption was made that RID=1 contained a single empty check-in. It worked, but it turned out problematic for fossil versions (< 1.37 or so), which still made this wrong assumption somewhere. It works by simply defining a virtual single check-in with RID=0, which is not actual a stored BLOB and so is not visible in the timeline.

It's a simple solution for the question coming back over and over again, asking what's the function of the initial checkin (this thread is another example .... ). My answer: Yes there needs to be an initial checkin, since that's what every other checkin originates from, but this checkin doesn't need to be stored actually as a BLOB. Just let it (virtually) be at a timestamp infinitely far back into the history. The problem with the current initial checkin is that it has a timestamp, so if you start committing check-ins from somewhere else (e.g. GIT) which happened in the past, time becomes warped. If the (virtual) initial checkin is infinitely far in the past, this problem is gone. That's what I was hoping to provide a solution for.

There's no need to do other special things at all: Just checkout out an empty repository (with empty BLOB table). You can start "fossil add"-ing files and finally commit them. The first commit will then become the initial commit, with any comment and any files you like. Just try it, it works!

So, If I provide a patch to put the "fossil init --empty" back, would it stay this time? I'm happy to test it again, in order to see if there are new places in the code where this assumption is - again - voilated. I have a few repositories created this way: No problem last time I checked.

Thanks for bringing this up again.

So again, the answer to "Why?" is just for one less step in a new repo process? This is simply a feature request on an easily solved problem, not because there's something broken with what you're doing?

Something as simple as... would be great.

It wouldn't be quite that simple, though. All files in a repo have to derive from a common root, and such an approach would require a way of allowing a user to say "this file belongs in dir x/y/z of the newly-initiated repo" for every file. How should something like this behave:

fossil init foo.fsl --add /foo/bar/baz.* --add /bar/baz/barre

(It's a rhetorical question intended only to point out a glaring pitfall.)

I read somewhere that, "In the beginning, there was nothing."

To me, that seems like a preferable initial state. That way, all the content gets added the same way. Problems that might show up under strange circumstances after a repo has been in use have a chance to show up near the beginning. There should be fewer code paths, and fewer test cases needed. All in all, a sensible approach.

The "extra work" Richard sees as necessary to "fix" this will likely add complexity, which should always been seen as a cost, only to be incurred where real benefit is obtained thereby. But the only "fix" benefit would be to conform to a way of viewing the problem where repos can have an infinite number of initial states. I would not view that as an improvement at all, and am not agnostic about it as an implementation detail.

I didn't mean to imply the implementing of this feature would be
quite so trivial, but that from the user-perspective, the action itself
is a simple task—it doesn't need to be complicated; from this brief
exchange I can already appreciate it requires some forethought else
it would already exist (or not have been removed).

I'll get a better idea of just how viable it is when I dig into the code.

I'll bite, though: what serves as the common root as it stands now?
The empty initial check-in? If so, what exactly does that provide that
an initial commit containing files can't provide?

... there are many places in the code that assume that the repository contains at least one check-in.

Reading this and related threads I've got an impression that it's the backwards compatibility that was the main reason to undo the --empty.

What if the first check-in sequence was somewhat reversed in the case of an empty repo, so that the check-in blob (the one with the expected rid=1 and type=ci) would be added first, followed by the file blobs?

What's the reason to require that the check-in blob has to be added after the file/delta blobs?

I'm not sure I see what is gained by delaying this infinite variability
to the second commit. The initial state is simply no repo, but a
repository of files is always going to be a composite of variables.

In any case, this wouldn't impel you to begin your repos any other
way than you presently prefer—you could keep initialising them with
nothing. It provides more choice, not less.

I'll bite, though: what serves as the common root as it stands now? The empty initial check-in? If so, what exactly does that provide that an initial commit containing files can't provide?

The common root is the top-most checkout directory. Since the initial commit contains no files, it isn't affected by this detail.

What's the reason to require that the check-in blob has to be added after the file/delta blobs?

The checkin process can only create the checkin manifest after all related blobs are in the database and their hashes have been calculated. If it were to allow blobs to be added to the db after the manifest is created, there would be a small time frame where a blob could be changed after its hash was calculated, invalidating the the checkin. The current approach is also needed for calculating the "repo checksum" (R-card in the checkin manifest), for related reasons. That checksum is part of the checkin manifest and is calculated from the content of ALL blobs in that checkin. Thus those blobs need to be in the db before the R-card can be calculated.

If the common root is ., can't it still be the common root
regardless of whether there are files in the directory?

If the common root is ., can't it still be the common root regardless of whether there are files in the directory?

"If", yes, but at that point you might as well create a checkout. i personally see no appreciable benefit from the hypothetical "init --add" if it supports adding files from only a single path. That's the same as opening a checkout there and adding them, except that it requires new code for a really fringe use case. i'm not a fan of that proposal, but as Warren so elegantly put it, fossil is a do-ocracy, so if someone who is itched by the problem implements it then i have no room to complain.

Heh...I like that term. I'll be borrowing it!

There is also

echo '' | fossil import --git new_empty_repo.fsl

as a workaround to create an empty repository without initial empty commit, emulating an empty git-fast-export dump as source.

But why bother in the context of converting from git. fossil import ... without the -i|--incremental option does create a repository with timeline starting from the initial commit, as defined by the git-fast-export stream feed into it.

I finally had some time so went to implement the --empty flag, and
Stephan was right—it's a trivial patch. I've not submitted it to a
battery of tests, and am not familiar with the previous bugs, but it
doesn't seem to have introduced any problems as yet.

I started reading the codebase to see about implementing this feature to
extend fossil init and accept some file(s) to commit with the initial
check-in, but am not sure about the best approach; for example, is it
something you would do with the db_initial_setup() subroutine or,
similarly to --empty, would you bypass that database write altogether
and call commit_cmd() to create a new manifest to write?

I don't have a clear enough mental picture of the internals so any
pointers would be greatly appreciated.

--- src/db.c
+++ src/db.c
@@ -2381,10 +2381,11 @@
 ** Options:
 **    --template      FILE         Copy settings from repository file
 **    --admin-user|-A USERNAME     Select given USERNAME as admin user
 **    --date-override DATETIME     Use DATETIME as time of the initial check-in
 **    --sha1                       Use a initial hash policy of "sha1"
+**    --empty|-E                   Don't create an initial empty check-in
 **
 ** DATETIME may be "now" or "YYYY-MM-DDTHH:MM:SS.SSS". If in
 ** year-month-day form, it may be truncated, the "T" may be replaced by
 ** a space, and it may also name a timezone offset from UTC as "-HH:MM"
 ** (westward) or "+HH:MM" (eastward). Either no timezone suffix or "Z"
@@ -2396,16 +2397,18 @@
   char *zPassword;
   const char *zTemplate;      /* Repository from which to copy settings */
   const char *zDate;          /* Date of the initial check-in */
   const char *zDefaultUser;   /* Optional name of the default user */
   int bUseSha1 = 0;           /* True to set the hash-policy to sha1 */
+  int bMakeEmpty = 0;         /* True to elide initial empty check-in */
 
 
   zTemplate = find_option("template",0,1);
   zDate = find_option("date-override",0,1);
   zDefaultUser = find_option("admin-user","A",1);
   bUseSha1 = find_option("sha1",0,0)!=0;
+  bMakeEmpty = find_option("empty","E",0)!=0;
   /* We should be done with options.. */
   verify_all_options();
 
   if( g.argc!=3 ){
     usage("REPOSITORY-NAME");
@@ -2422,11 +2425,11 @@
   db_begin_transaction();
   if( bUseSha1 ){
     g.eHashPolicy = HPOLICY_SHA1;
     db_set_int("hash-policy", HPOLICY_SHA1, 0);
   }
-  if( zDate==0 ) zDate = "now";
+  if( zDate==0 && !bMakeEmpty ) zDate = "now";
   db_initial_setup(zTemplate, zDate, zDefaultUser);
   db_end_transaction(0);
   if( zTemplate ) db_detach("settingSrc");
   fossil_print("project-id: %s\n", db_get("project-code", 0));
   fossil_print("server-id:  %s\n", db_get("server-code", 0));

I started reading the codebase to see about implementing this feature to extend fossil init and accept some file(s) to commit with the initial check-in, but am not sure about the best approach; for example, is it something you would do with the db_initial_setup() subroutine or, similarly to --empty, would you bypass that database write altogether and call commit_cmd() to create a new manifest to write?

The "gold standard" for understanding the internals of the checkin process is commit_cmd(), but you might also find test_ci_mini_cmd(), in fileedit.c, helpful in understanding the checkin process, as it also performs a checkin, but is limited to a single file and doesn't deal with the checkout database like the commit command does. Similarly, a checkin made at init-time also wouldn't have a checkout db.

The end result may well be a hybrid of commit (which supports any number of files but requires a checkout) and test_ci_mini_cmd() (which commits without a checkout but only supports a single file).

It "might" (or might not) make sense to extend the fileedit infrastructure to work with multiple files, but that would be a relatively invasive (but also fairly straightforward) change to the fileedit.c-provided features.

It also "might" (or might not) make sense to not do that, and instead use the data structures which the commit command uses, as those already support any number of files and additional features like tags (which "could" be used to provide an initial branch name to the initial commit at init-time, for those who don't want to use the name "trunk").

In the case of an initial commit, at least one part will be simpler than both commit and /fileedit: there's no need to derive a list of modified files. However, the files must be inserted into the new manifest in proper sorted order or the manifest will be considered corrupt.

One hurdle you're going to run into if you decide to add support for adding files at init-time is how to handle files which have no common top-level directory, e.g.:

fossil init foo.fossil /path/to/file1 /other/path/to/file2 ...

You'll see what i mean as soon as you try it! There are at least two feasible approaches to solving that, the simplest one being not to permit it, instead requiring that all added files to have a common ancestor directory (other than the root of the filesystem).

Good luck!

In any case, this wouldn't impel you to begin your repos any other way than you presently prefer—you could keep initialising them with nothing. It provides more choice, not less.

Purely from a user's perspective, I somewhat agree with that choice point, where commands have not become overly cluttered with options. However, I was addressing code complexity. I know from my own programming experience that it is frequently the case that a well-known starting condition can make for simpler code or reasoning about code.

Most of the VCS's I've used have a create repository command which produces an initially empty repo, with creation followed by usage (add file(s), etc.), which is also a simpler mental model. It might be an extra typed word (from the CLI) or some extra mousing (from a GUI), but the operations separate orthogonally, which to my way of thinking is simpler. This may be because I long ago became an adherent and fan of the Unix Way, particularly in preferring composable simple invocations to more complex do-it-all invocations.

Thanks, Stephan. I appreciate the insight, and you've given me enough to
make sure I'm not getting lost in the weeds.

Regarding the hurdle, I was considering the approach to which you
alluded; it's my most common use case and, as you say, the simplest
solution. But I'm not wedded to this approach either.

@jan.nijtmans also worked/(?s) on this functionality.

It maybe more productive if both of you could collaborate on this, especially on the backward compat aspect that led to rolling back of the previous implementation.

P.S. Does Fossil support @-mentions?

P.S. Does Fossil support @-mentions?

Nope, but patches are thoughtfully considered. Keep in mind that any implementation must avoid sending any @-notification until a post is past moderation, must avoid repeated notifications on edits (while allowing for new @mentions in those edits), and must avoid repeated notifications when a repo is cloned and its posts get processed anew in the clone.

What is a "@-mention"?

In many systems nowadays, typing @drh would send you a direct notification that someone had mentioned you in a ticket/comment/whatever. It's generally a useful feature but could easily lend itself to abuse when posters specifically try to draw your attention to their ostensibly high-priority questions. Obviously, users can disable such notifications on all systems which support them, and some systems allow more fine-grained control, such as only sending such notifications if @drh had previously participated in the current thread.

This particular form of mentioning has been invented on Twitter, then spread over the rest of WWW. Some niche communities (like OpenBSD mailing lists) insist on the older meaning of user@host and put the @ after the nickname they want to mention.

Sure. That sounds good.

Thanks to Stephan's advice, I've read up on the relevant internals and,
to make sure I had a decent enough understanding of the check-in
process, have written the bare basis of Richard's idea for the --add
option. It accepts a file that is committed to the repository with an
optional message argument for the comment of the first check-in. I've
committed to a local private branch, do you want to create a new public
branch for collaboration or is there already another suitable branch?

I saw jan@ committed the --empty option to the
no-initial-commit branch a few days ago, but I'm not sure if that's
an apt branch for this feature set.

I saw jan@ committed the --empty option to the no-initial-commit branch a few days ago, but I'm not sure if that's an apt branch for this feature set.

Yes, that's exactly what it is for.

Demo (do this in some empty directory):

$ fossil new --empty empty.fossil
project-id: f1c7a77273fac9c1ab04bd9d980e8da08f1acb56
server-id:  a20b372c626c28337c3c4d61036d77c1dde052e0
admin-user: ???? (initial password is "???")


$ fossil open empty.fossil
project-name: <unnamed>
repository:   /<path>/empty.fossil
local-root:   /<path>/
config-db:    $HOME/_fossil
project-code: f1c7a77273fac9c1ab04bd9d980e8da08f1acb56
check-ins:    0

$ touch xxx.txt

$ fossil add xxx.txt
ADDED  xxx.txt

$ fossil commit -m "my first commit"
New_Version: 2dda507410e2e93abe47727a60f34c134936a5f3599f80054429b3241ee71186

$ fossil timeline
=== 2020-07-08 ===
14:05:39 [2dda507410] CURRENT my first commit (user: Jan.Nijtmans tags: trunk)
+++ no more data (1) +++

Now you have a repo with an initial commit. You specified the files in it and you specified the commit message, just by using already existing fossil commands. It's really that simple.

I think you might've misunderstood to what I was referring.

The branch is obviously well suited for the --empty option, but I'm
not sure if it's the right branch to commit the patch that I'm working
on to implement the feature Richard suggested, which is why I asked
if you wanted to create a more suitable branch to collaborate (if that's
something you want to do):

$ fossil init tmp.fossil --add main.c -m "Initial commit."
project-id: 2d7432dd4d809c51d75eca7f9e113fb1ab3afe93
server-id:  54fd5ff67bd4321f5ee66e23c1928c9883415b19
admin-user: mark (initial password is "MmZP6xsaV5")
$ fossil open tmp.fossil
project-name: <unnamed>
repository:   /home/mark/dev/tmp/fossil/tmp.fossil
local-root:   /home/mark/dev/tmp/fossil/
config-db:    /home/mark/.fossil
project-code: 2d7432dd4d809c51d75eca7f9e113fb1ab3afe93
checkout:     e56828d4734eeede31ab2da16e0a830681768006 2020-07-08 08:32:56 UTC
tags:         trunk
comment:      Initial commit. (user: mark)
check-ins:    1
$ fossil timeline
=== 2020-07-08 ===
08:32:56 [e56828d473] *CURRENT* Initial commit. (user: mark tags: trunk)
+++ no more data (1) +++
$ vi main.c
$ fossil status
repository:   /home/mark/dev/tmp/fossil/tmp.fossil
local-root:   /home/mark/dev/tmp/fossil/
config-db:    /home/mark/.fossil
checkout:     e56828d4734eeede31ab2da16e0a830681768006 2020-07-08 08:32:56 UTC
tags:         trunk
comment:      Initial commit. (user: mark)
EDITED     main.c

I didn't want to push to an inappropriate branch, but if no-initial-commit
is also suitable for this feature set, I'm happy to push it there.

What I'm trying to say is that the order of commands is not logical:

You basically use 2 commands up to the initial commit:

$ fossil init tmp.fossil --add main.c -m "Initial commit."
$ fossil open tmp.fossil

So, you already add a file "main.c" to the repository, even before opening. You can reach exactly the same end-situation by:

$ fossil init --empty tmp.fossil
$ fossil open tmp.fossil
$ fossil add main.c
$ fossil commit -m "Initial commit"

The advantage is that you don't have to specify the initial commit in one single command. You can add files to it, set tags, whatever, and see in "fossil status" whether the initial commit contains everything you want. If not, you can adapt it further (remove files or add other ones). Finally, when you're satisfied, you do "fossil commit" and the initial commit is there. That's the workflow I propose. It already works today.

So, this way, creating an initial commit is exactly the same as any other later commit. Nothing new to learn.

The advantage is that you don't have to specify the initial commit in one single command.

... So, this way, creating an initial commit is exactly the same as any other later commit. Nothing new to learn.

FWIW, i agree 100%. Adding files at init-time seems like an oddball feature to me. The arguments i've seen for it so far seem to imply that the use cases for it are effectively using fossil as an alternative to zip or tar files, which also seems oddball to me.

But the world would be a mighty strange place if we were all the same.

Sure, you can reach the same place with the --empty option. That's
what I initially requested, so I'm pleased to see it brought back and am
more than happy if that remains.

To be frank, I hadn't thought of this at all till Richard mentioned it
earlier ITT. It was only after how trivial it was to implement the
--empty option that I decided to write this up too; I'm on holidays
for another week so I had the time. Although I don't agree that it's
illogical, there are only a few occasions where I know I would presently
use this proposed feature set (e.g., simple scripts that I've already
written up that I want to commit to version control, config files
[though I tend to use rcs(1) for this]) so, for me, it's not important.
Though I can imagine—like many things—its utility might be more apparent
if it were available.

That said, it's just about complete so I may as well see it finished.
It's not either --empty or this—they can coexist—so in those instances
where I already know what I want to commit, this is markedly quicker,
which is always nice.

I'll keep it local so if anyone else has a use for it, let me know and
I'll shoot through the patch.

The remaining question is to find out if the resulting repo is backwards compatible with older clients (expecting ci at rid:0). Is there the testcase(s) that was breaking in previous incarnation of --empty?

Such versions (all older than 2014-ish) should only fail with an empty repo. Presumably nobody's going to host an empty repo. To the best of my current (fallible) recollection, there was never a requirement/assumption that rid 1 was a checkin, but older versions often assumed that the db had at least one checkin. Part of the reason for the empty initial commit was to "seed" the db, simplifying downstream code by allowing it to assume that there was always data to process.

The above does not work on Windows at least. But this does:

fossil import --git empty.fossil < nul

That's because quoting is screwy on Windows, since command.com and its modern descendant cmd.exe have a far more limited form of it than even the 1979 Bourne shell. Still. In 2020.

Microsoft removed their cmd.exe reference material some years back, but according to that linked reference — the best I've found in multiple searches over those years — it doesn't support single-quoting at all. I therefore expect what that command does is passes two literal single quote marks to Fossil on Windows, which isn't a valid git-fast-export repo stream, empty or no.

However, it makes me wonder: does this work instead?

    C:\> ECHO. | fossil import --git empty.fossil

...cmd.exe have a far more limited form of it than even the 1979 Bourne shell.

I just fired up my copy of UNIX V5 from 1974, and even the Thompson shell gets this right.

It was probably coded on a Teletype. On paper. With a line editor.

No, same problem.

https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19845.html

"I rue the day that I allowed that patch to land on trunk."

2015

Such versions (all older than 2014-ish) should only fail with an empty repo.

Yes, empty repositories are incompatible with Fossil versions < 1.28 or so.

Since the default hash-policy for newly created repositories is now "shun-sha1", any repository created by Fossil 2.11 cannot be handled by Fossil versions < 2.0 anyway. Every fossil version >= 2.0 can handle empty repositories, since this bug was solved long before that.

The challenge here is to convince @drh on that, so far I didn't succeed on that. So, please try it (recipe above) and report back here that it works!

Thanks!