Service disruption: git converter currently down

[Ulrich Spörlein]

Am Mo., 23. Sept. 2019 um 19:51 Uhr schrieb Sean Chittenden
<sean at chittenden.org>:
>>
>> Please note however, that more "garbage" metadata escaped from SVN into
>> github, meaning 3rd parties have a hard time re-running the conversion and
>> making sure that it matches SVN down to the metadata (i.e. timestamps).
>>
>> Eventually, this will have to be re-rolled and a new "master" branch will
>> be force-pushed into github. There's no timeline for this yet.
>
>
> Wait, what?  Can you elaborate?
>
> Discussion of a force-push to github has occurred a few times and been explicitly ruled out because most of our corporate citizens use github to integrate changes from FreeBSD.  Rerolling master was universally rejected when we socialized wanting to do this due to the level of disruption this would cause.  The feedback was that this would be a high-cost, low-value operation.  In the tradeoffs of purity vs pragmatism, pragmatism wins every time (that is the FreeBSD way).
>
> -sc


This is not just about pragmatism and the disruption it would cause is
vastly overblown by people who don't seem to know much about the git
storage model.

There *is* garbage metadata in the published version on github, there
*is* a disclaimer on https://wiki.freebsd.org/GitWorkflow since
forever, and the cost of switching from 1 published branch to another
is literally:

- git diff origin/broken_master mybranch > mybranch.patch
- git checkout -b fixed_branch origin/fixed_master
- patch < mybranch.patch

It should also be possible to merge both broken and fixed master into
your branch (at the exact same SVN revision in time) and then you can
follow fixed_master going forward. You'll schlepp around double the
commit history, but not tree objects.
If you want to retain history, you can upstream the changes prior to
the switch, or do something more elaborate with git filter, maybe.
This should be no surprise to anyone who's been reading up on the
conversion workflow or following the various email threads.

It is currently impossible to re-create the published repo w/o doing
elaborate SVN metadata surgery. That is no state to be in, it is not
pragmatism.

hth
Uli