Fossil Forum

`import --git` email address check-in attribution
Login

`import --git` email address check-in attribution

(1) By jamsek on 2020-11-06 13:09:15 [link] [source]

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?

(2) By Richard Hipp (drh) on 2020-11-06 13:22:22 in reply to 1 [link] [source]

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.

(3) By jamsek on 2020-11-06 13:41:57 in reply to 2 [source]

That's a better idea; it's more consistent with Fossil and, like you
mention, more robust code. Thanks, drh. I'll start on that now.

(4) By Warren Young (wyoung) on 2020-11-06 21:43:11 in reply to 3 [link] [source]

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.

(5) By jamsek on 2020-11-09 15:24:02 in reply to 4 [link] [source]

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?

(6) By Warren Young (wyoung) on 2020-11-09 15:48:36 in reply to 5 [link] [source]

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.

(7) By jamsek on 2020-11-12 15:00:29 in reply to 6 [link] [source]

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.

(8) By Warren Young (wyoung) on 2020-11-12 22:57:08 in reply to 7 [link] [source]

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

(9) By jamsek on 2020-11-13 01:37:12 in reply to 8 [link] [source]

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?

(10) By Warren Young (wyoung) on 2020-11-13 04:12:13 in reply to 9 [link] [source]

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.

(11) By jamsek on 2020-11-13 04:30:03 in reply to 10 [link] [source]

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.