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.

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

See /forumpost/aebc7fbb05.

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.

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.

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.

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.

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?

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.

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

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

repository already exists; proceeding as an incremental import.

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.

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

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.

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.

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.

It turned out to be a fun itch to scratch! It's led to a much deeper
understanding of Fossil's internals, and even more appreciation for its
cohesive and consistent design while highlighting more of Git's
annoyances. I wasn't able to test it on Windows, though, for lack of a
Windows box; so if you're able, or can arrange someone else, to test this
check-in on Windows, that would be good. In brief, if a repository
file exists and neither --increment nor --force has been passed, rather
than return that error you reported, it will prompt the user to continue
with an import that will only add any new commits that don't already
exist in the repository. This took a bit of work to avoid inserting
duplicate artifacts. Otherwise it notifies the user to either use --force
to overwrite or manually delete the file, or provide an alternative
filename. Please let me know if you'd prefer some other response. I ran
a battery of tests on OpenBSD and macOS, and its behaving as expected
but that's not to say it's the desired or preferred behaviour. We could
instead exit with an error or prompt to overwrite. Any of these options
are reasonable, I think.

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?

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.

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.