Re: FYI: SVN to GIT converter currently broken, github is falling behind

On 11/5/15 6:46 AM, Ulrich Spörlein wrote:
> 2015-11-04 18:57 GMT+01:00 Ulrich Spörlein <uqs_at_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:
> https://github.com/freebsd/freebsd/commit/bf66c97c4a64e64410bf0223d221a54ca9555f52
>
> 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.
>
Uli,

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 _at_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.

-Alfred