In converting some Git repositories to Fossil, irrespective of using the
--use-author option to fossil import --git, the user attributed to each
check-in is the email address of the Git user. So I'm digging into the
code to see why and/or if I can implement an option to use the username
corresponding to a given email address. It looks like Fossil tries
to find the login value of the full Git author or committer string in
the Fossil repository database and, if there's no entry, the email
component of the Git username emailaddr string is used. I'm assuming the
gg.zUser check on line 672 in import.c will always be NULL when it's a
brand new repository (not an --incremental import into an existing one)
because the user table is yet to be populated. So I'm thinking about
adding an option that takes a filename argument with line entries of the
form emailaddr username (or similar) from which the username can be
matched to the email address Fossil currently parses and assigned to
gg.zUser.

Or do I have this wrong and there's already a way to have a username
rather than an email address attributed to each check-in of a brand new
import? If my synopsis is correct, what are Fossil users presently doing
when importing Git repositories to attribute a username sans email
address to each check-in?

Sounds like a good plan to me. Except, I might prefer that the named file to be an SQLite database rather than a flat-file. That would result in less code, as you don't have to write code to read and parse in the input file. Instead you can query the table directly. You also avoid problems with quoting of special characters in the username or email address.

Would it be useful to make this an "fx_" table within the repo DB, so you don't have a second database to keep track of?

A consequence of this is that the table will then be queryable from TH1 in the repo, since it will pass the SQL authorizer. I don't know if that's a good thing or a bad thing.

Please excuse the tardy reply—I didn't get a chance to start on this til
today with an unexpected busy weekend. I'm not familiar with fx_ tables
but I ended up populating a temp table for the time being and it's doing
the job. Though we probably want something less ephemeral so the same
data can be used for this problem. I'll look into using fx_ tables
instead. A cursory search of the site didn't return much; can you point
me to somewhere I can start?

The feature's undocumented, as far as I'm aware.

It's just a way to mark a table as being a "Fossil eXtension" so a rebuild command doesn't nuke it. I don't believe you get anything like syncing on such tables for free.

Thanks, Warren. I ended up replacing the temp with an fx_ table and it
afforded a lot more utility. Now the same information can be used to
attribute commits to the original Git committer when exporting, which
should help keep consistent commit attribution when mirroring.

You should document the fx_git feature, soon, particularly since you've made these modifications directly to trunk.

I have started, though wasn't sure where best it should go. Apart from
the embedded help I wrote for the --attribute option, I'm thinking about
adding to the Import and Export documentation. Other locales considered
and dismissed were Git to Fossil and How to Mirror. Where would you
suggest it's added?

I think the "Mirroring to GitHub" doc is the place I'd expect to find that info. The other two can link to that presentation.

Okay. I'm glad I asked because I'd initially dismissed that doc, but it
actually makes more sense as that mentions the new git export. And
I'll put the documentation for the --attribute option on the Import and
Export page as that references the "old" import --git, and link back to
the Mirroring to GitHub page. Thanks, Warren.

On a somewhat related note, is the rewrite of the import --git to the
new git import implementation under active development? I have some
holidays forthcoming so could help.