what would be the recommended way to get standard fossil naming (trunk branch called "trunk" and no other tags attached by default)?

Perhaps simplest is to manually rename it after importing. Run "fossil ui", visit the timeline, find the first check-in, and edit it with the "make this the start of branch X" feature, with X=trunk.

thanks! that was too easy and too obvious ;). or rather: in fact, I did not try this because I expected this just would create another branch named "trunk" besides "default" starting at first checkin...

so I do not really understand why this works: why does no spurious "default" branch remain after the "make first check-in start of (new?) branch trunk"?

that much -- branches identified by propagating tags -- I am actually aware off :P. my difficulty was (still is ...) that I interpret

"Make this check-in the start of a new branch named X"

in the GUI edit option for a checkin as creating a new branch branching off from the specified checkin. or is this a misconception?

at least in the present case (when doing this on first checkin of the repo) it seems to actually enact a rename from (in this specific case) "default" to "trunk" as the branch name.

I also do not quite understand what happens exactly during the fossil import: as said all checkins carried two tags: 1. "default", 2. "trunk", where "default" was the actual branch name. so what is the "trunk" tag doing there at all?

but anyway, repo now looks good after all :).

... in the GUI edit option for a checkin as creating a new branch branching off from the specified checkin. or is this a misconception?

It's not a new branch in the sense that it's branching off from the original while keeping the original intact. It's new in the sense that that line of the tree is being assigned a new symbolic name starting at the given checkin. We could possibly relabel that as "rename branch to..." but whether or not that would be semantically correct, vis a vis the internals, is up for debate.

... so what is the "trunk" tag doing there at all?

That one's above my proverbial pay grade ;).

"Starting with this commit, rename the branch to X"

Though this seems more of a case of "learned behavior". Thoughts?

The origin of the confusion is, in hindsight, obvious and it now seems odd that this confusion hasn't (AFAIR) come up before. Changing the label to specifically indicate a "rename" instead of implying creation of a new branch seems sensible to me. FWIW.

Perhaps simplest is to manually rename it after importing.

Now that i'm back on a keyboard, there's a simpler way to do it. From a checkout:

$ fossil amend --branch trunk root:tip

should do the trick for most repositories. In some (like fossil's own), the "root" may resolve to somewhere other than the first checkin. In place of "root:tip" you can also use the hash of the first checkin.

Unfortunately, i can't answer the underlying question of why the import options don't rename the branch for you. git import/export is, quite fortunately, something i've never needed to touch.

thanks! I will make a screenshot of this and try it out in due time;).

you are also right in that the actual question indeed is why the rename does not happen during import. maybe fossil only recognizes the git default name ("master") but does not do sof for hg which calls trunk "default"? it's no big deal but of course minimally annoying that one has to intervene manually after the import along the lines you suggested in order to restore a "sane" branch name.

regarding fastexport, I am just happy that hg did provide/support this option and that fossil import can read it. principally it's a nice and easy way to migrate a repo from hg (or git, naturally) to fossil (or the other way around I think?). which is nice.

I am a beginner with mercurial but feel confident with fossil (and using it every day a lot already for many years).

Now I got a big folder with a mercurial repository and wonder how to convert it into a fossil repository. Your post was my trigger.

• I am running on Windows, so I installed the TortoiseHG 6.4.2 MSI installer - x64 Windows 10+.

• After looking for some hg help I was able to find the info how to enable the fastexport extension.

• Then I tried your approach; but in my case it seems not to be as simple as in yours.

D:\project\hg-pro>C:\UserPrograms\Mercurial\hg.exe fastexport>fe.txt
abort: Unable to parse user into person and email for revision >3968867b36b16523ccbfde4519c5d674cec33f2b

D:\project\fsl-pro>fossil.exe import --git proj.fossil ../hg-pro/fe.txt
Rebuilding repository meta-data...
 100.0% complete...
Vacuuming... ok
project-id: 0195cd9da20fb8ec7bad4a31dd4c99922dbb00cd
server-id:  c4705cd3cbb2e9480dc4cbd14d592d57c3e8815d
admin-user: XXXXXX (password is "YYYYYYYYYY")

The result is an initial checkin with "all" the files of the project init but not the whole history.

Can you give me a hint how to overcome the errors, please?

sorry, no idea. I am not a mercurial expert either. but it seems the problem indeed happens during the `hg fastexport' so that you might look for help on the mercurial mailing list?

I searched for help and got the new chat-bot of Bing, which helped me with its 5 questions-per-day limit to find locations and format of the username, which is just firstname lastname <and@an.email>

What I found is that my trouble-causing change-set (and maybe more later on) has a user but is set with double-quotes, which is the unexpected format that aborted my trial. The preferred username can be set with the hg workbench (thgw.exe) ->File ->Settings ->Commit ->Username or ->EditFile, it is without any quotes or double-quotes.

I think once I would find a way how to re-assign the user name into the repository contained history change-sets or how to ignore its parsing then the command hg fastexport would (probably and hopefully) succeed.

Sorry for noising this thread. The way "how to" is now clear to me and my findings so far will be of some help as well for someone.

I succeeded by doing the following steps:

• searching all the format disturbed user entries, there were just 2 in my case, which were used multiple times
• creating the file authors.convert.list with a "from disturbed" to "well formatted" list
• enabling in the thgw.exe the extension convert
• calling command line: hg convert --authors authors.convert.list mercurial-repo-dir

It took a long time in my case to convert the whole repositiory into a corrected new one. But from that new converted report it was as described above an easy step to do the hg fastexport and the fossil import --git . It took its time but it worked.

Some metrics:

• original mercurial repository (.hg folder): 202 MB file sizes, 288 MB on data medium
• new mercurial repository (.hg folder of the converted original): 132 MB file sizes, 217 MB on data medium
• fastexport'ed text file format from mercurial repository: 2.53 GB
• localhost:8080/stat :
  • file size: 166 MB after import from text file
  • Compression Ratio 96:1
  • Number of check-ins: 10663
  • Number of files: 26746
  • Duration of project: 2924 days or approximately 8.01 years
  • Database stats: 42401 pages, 4096 bytes/page, 0 free pages, UTF-8, delete mode
• after fossil rebuild --wal --compress:
  • file size: 165 MB
  • Compression Ratio 97:1
  • Repository rebuilt: By Fossil 2.21 [f9aa474081]
  • Database stats: 42188 pages, 4096 bytes/page, 0 free pages, UTF-8, wal mode

Thanks again for all the inspiration and hints.

EDIT: Duration of project correction by using fossil amend --date on two wrongly dated check-in's