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 ...
(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
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
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]
(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:
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 <email@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 <firstname.lastname@example.org>>
Seems to me there are sufficient
>chars in that ident string. None are missing that I can see. :)
fossil import --gitdoesn'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
(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
or (b) Fossil presents a dialogue notifying same, and prompting the user
for input to proceed as an
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.
(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]
--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]
--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.
(20) By jamsek on 2020-11-28 14:14:16 in reply to 9 [link] [source]
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
--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
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.
(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
(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
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.