Fossil Forum

Feature Request: User field for git email and git name
Login

Feature Request: User field for git email and git name

(1) By anonymous on 2020-11-06 14:41:49 [link] [source]

Hello! I wish there would be a way to set the git name and git e-mail for a specific fossil user which is then being exported by "fossil git". The motivation behind this is that I want to mirror my Fossil repositories to my GitHub account and I would like to associate them with my real name and real E-Mail instead of just my plain fossil username. My current approach is piping it through sed several times but this seems quirky and unreliable.

(2) By Stephan Beal (stephan) on 2020-11-06 14:43:43 in reply to 1 [link] [source]

I wish there would be a way to set the git name and git e-mail for a specific fossil user ...

See /forumpost/aebc7fbb05.

(3.1) By jamsek on 2020-11-06 15:21:43 edited from 3.0 in reply to 1 [link] [source]

As of this check-in if you build from trunk you can set user contact
information with fossil user contact $USER $INFO but I'm not sure if
it's this information that's used by git export to attribute commits in
the Git repository. That might be something I can look into after sorting
out this issue going the other way from Git to Fossil as Stephan pointed
out. Maybe fossil git export could take the same SQLite database file
to match the Fossil username to the Git name emailaddr string to be used
for Git commit attribution.

(4.1) By jamsek on 2020-11-12 14:53:33 edited from 4.0 in reply to 1 [link] [source]

Please try check-in [52fb87ba50] and—if your user contact info
is not already set then do so with fossil user contact—and
see if exporting to a Git repository now attributes commits to your full
user <emailaddr> information.

(5) By Warren Young (wyoung) on 2020-11-19 08:02:57 in reply to 4.1 [source]

I've just tried this new feature, and it's got a few significant weaknesses:

  1. The "contact" feature assumes the Contact Info field contains just a bare email address, but it's common practice to use RFC 822 style contact info here: Warren Young <wyoung@example.com>. The feature should be able to parse the email address out of this. Currently, it gives this unhelpful error instead:

    fatal: Missing > in ident string: wyoung <Warren Young <warren@example.com>>
    

    Seems to me there are sufficient > chars in that ident string. None are missing that I can see. :)

  2. fossil import --git doesn't check for an existing repo if you have to run it twice, such as because it didn't convert right the first time. You get this strange error:

    SQLITE_ERROR(1): table blob already exists in "CREATE TABLE blob(
      rid INTEGER PRIMARY KEY,
      rcvid INTEGER,
      size INTEGER,
      uuid TEXT UNIQUE NOT NULL,
      content BLOB,
      CHECK( length(uuid)>=40 AND rid>0 )
    );
    CREATE TABLE d
    Database error: table blob already exists
    

    It's clear in retrospect that it's colliding with the existing schema, but Fossil should diagnose this condition.

(6) By jamsek on 2020-11-19 13:09:55 in reply to 5 [link] [source]

Good point regarding the use of RFC 822 for the contact info field. I
think that error is coming from Git because in the case that a user has
used RFC 822, we're using the entire field, which Git doesn't accept.
It's a trivial fix, though, I'll patch it now.

Regarding point two, I'm not sure if that's a result of this feature but
I'll take a look.

(9) By Warren Young (wyoung) on 2020-11-19 16:22:37 in reply to 6 [link] [source]

Regarding point two, I'm not sure if that's a result of this feature

I'm sure it isn't, but I thought you might find it sufficiently itchy to be worth scratching.

(11) By jamsek on 2020-11-22 06:33:23 in reply to 9 [link] [source]

I'm going to dig into this later tonight so will let you know. I suppose
I could emulate this by importing into an existing repository without
the --incremental option?

(12) By Warren Young (wyoung) on 2020-11-22 07:43:34 in reply to 11 [link] [source]

Yes, I did indeed not use --incremental. The solution may therefore lie in looking into why Fossil didn't demand that I give it, rather than bull forward blindly until it ran itself into trouble.

(13.1) By jamsek on 2020-11-22 11:32:34 edited from 13.0 in reply to 12 [link] [source]

I've identified the problem and have developed a fix that silently
proceeds as though the --incremental option was passed; however, would
you prefer (a) Fossil exits and notifies the user that a repository with
the provided name already exists—please run again with --incremental;
or (b) Fossil presents a dialogue notifying same, and prompting the user
for input to proceed as an --incremental import?

Personally, I prefer the silent, implicit behaviour as it's invariably
going to happen; the other approaches both require more input from the
user to do the same thing.

ETA: s/export/import

(14) By jamsek on 2020-11-22 11:38:16 in reply to 13.1 [link] [source]

Maybe proceed as an incremental import but output a message; something
to the effect of:

repository already exists; proceeding as an incremental import.

(15) By Warren Young (wyoung) on 2020-11-22 11:47:21 in reply to 13.1 [link] [source]

Implicit --incremental is wrong, because one of the common reasons this happens is that you mess up the conversion and want to start over. Wouldn't your fix result in a repo that has multiple copies of converted artifacts in that case?

I'd guess that incremental conversion is far more often used for special situations, not at all the main use case. You could bring over one branch at a time, each with per-branch modification chains, for example. Or, you could use the feature to merge multiple source repos into the target. The main use case is a wholesale conversion of a single repo, is it not?

Of your two alternatives, I think neither is wholly correct. I think you want Fossil to exit, saying something like "The destination repo already exists. Pass --incremental to extend it, or remove it and retry to replace it." I don't see how the program can guess correctly at a rate any better than population statistics. That is, if 80% of the converted repos are wholesale conversions of a single repo, then I'd expect a default of "delete target repo and retry" to be correct 80% of the time, with no sane amount of logic in the tool able to improve those odds.

If the tool could guess correctly with high reliability, then I'd say you should make it do so, but I don't.

(16) By Warren Young (wyoung) on 2020-11-22 11:49:16 in reply to 15 [link] [source]

Also, if implicit --incremental made sense, then why is the flag there? Surely its presence means conversions are normally not incremental?

(17) By jamsek on 2020-11-22 12:00:34 in reply to 16 [link] [source]

I was thinking that if the repository is present, then an incremental
import is the only option; but, you're right—this is wrong—deleting the
repository and starting afresh is an option. I could check to see if
the outcome of deleting and reimporting anew or proceeding incrementally
produces different results. I think it would, but I don't know.

(18) By Peter Lane (peterlane) on 2020-11-22 12:43:30 in reply to 17 [link] [source]

I was hit by this last night as I tried various options to import a git repository in just the way I wanted. Once I knew what was happening, I got into the habit of deleting the previous repository.

But if you're changing the behaviour, I suggest a variation of your (b). For example:

$ fossil import --git ...
There is an existing fossil repository of that name, 
but you have not used the --incremental option. 
Proceeding will overwrite existing repository.
Proceed? Yn

With a default "yes" option, so I can just press enter and continue, deleting the existing repository. The "no" option would exit.

(19) By jamsek on 2020-11-22 13:42:36 in reply to 18 [link] [source]

There's the --force|-f option to overwrite the repository if it
already exists, so I'm reluctant to introduce redundancy where Richard
has already provided a solution. However, that assumes the user is
aware, which in the example scenario isn't the case. I think I've got
the simplest fix, though, which simply avoids recreating the repository
if it already exists, proceeds silently, and avoids re-adding existing
artifacts; however, it needs to be tested further. It's a little late
here, though, so I'll finish testing tomorrow.

(7) By jamsek on 2020-11-19 13:41:18 in reply to 5 [link] [source]

Thanks for the bug report, Warren. Can you please let me know if this
[check-in] solves the problem regarding incorrect RFC 822 parsing for
you?

(8) By Warren Young (wyoung) on 2020-11-19 16:21:48 in reply to 7 [link] [source]

Yes, that seems to have gotten it, assuming what you want in the output is "$FOSSIL_USER <$EMAIL_ADDR>". Perhaps someone would prefer to just have the contact info copied over literally, but I don't suppose GitHub cares, and I think it's helpful that the Fossil user name is preserved in the Git export like that.

Incidentally, this is more than just cosmetic: in Fossil repos making use of the self-registration feature, the user's "Display Name" and "Email Address" fields gets stored in RFC 822 format. This in turn is often enabled to allow for public forums like this one, which then use the display name in displaying posts. Point being, supporting this contact info format is rather important, so thanks.

(10) By jamsek on 2020-11-22 06:25:15 in reply to 8 [link] [source]

That is the output I intended with the reason being it provides a
consistent cross-reference for attribution between the Git and Fossil
repositories. I'm not married to it, though, so would happily consider
arguments for the alternative. Or we could add a switch so users can
select for realname <emailaddr>, otherwise it defaults to the current
format (or contrariwise); but I think that's adding a little too much
complexity. While it won't happen anytime soon, I'm making a concerted
effort to abandon Git entirely—not even mirrors—so would weight your
preference for the default format of the committer string; or someone
else who intends to use this feature in the longterm.