On 11/5/15 6:46 AM, Ulrich Spörlein wrote:
2015-11-04 18:57 GMT+01:00 Ulrich Spörlein <u...@freebsd.org>:
The recent SVN update on the cluster broke svn2git in certain circumstances.

To fix this and make sure no content was dropped, the converter has
been stopped and we're working on bringing a fixed version online, as
well as vetting the correctness of the published git repositories.

ETA is currently unknown, expect an update to this thread within 24h.
Sorry for the inconvenience!

Uli, on behalf of git-admin
An independent run of the converter produces a different git
repository starting at the commit following this one:

This is from 9d ago and will likely require a force push to github
that will necessitate people to rebase or merge there work (a
fast-forward merge will fail).

This is the preliminary inspection and a third verification run is
currently underway. Expect another update within 24h.


One of the biggest concerns I've heard from folks using FreeBSD's git mirror is that the hashes can change.

I have a question about this. Is it possible to keep track of what the "official" git mirror (on github) is doing and keep that as a log. Then that log can be used to replay commits when there is a divergence problem.

What I'm basically saying is that let's take this small example:

importer is working fine @rev 10000
imports 10000
imports 10001
imports 10002
something happens to importer to give indeterminate shas.
imports 10003 - sha is "unstable" sha3
imports 10004 - sha is "unstable" sha4
imports 10005 - sha is "unstable" sha5
imports 10006 - sha is "unstable" sha6
importer is fixed

At this point normally we'd rewind the importer to 10002 and then force update the affected branches.

My question is... can the imports of 10003, 10004, 10005 and 10006 be put into the importer such that any "mirror site" that re-does the import using the most up to date importer will get the same shas.

That would allow to proceed with 10007, etc without force pushing.

This should be possible based on querying "git" for the meta data associated with sha3..sha6 and then forcing those commits to have the same meta data.

This would eliminate the concern about shas in the mirror changing that I've heard.


freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to