Service disruption: git converter currently down

[Warner Losh]

On Mon, Sep 23, 2019, 8:16 PM Ulrich Spörlein <uspoerlein at gmail.com> wrote:

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

Not a viable option. We have hundreds of commits in our tree at work and
this would destroy the history there.

A crazy set of rebase might work, but that's tricky too and would need to
be scripted. It's possible, but a lot of pain for what most people will
regard as zero real gain.

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

We are long past this warning being enforceable.  This would hit about 100
branches I have in progress.

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

We know this. The pragmatism is that we don't really need to be that pure.

Warner

hth
> Uli
> _______________________________________________
> freebsd-git at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-git
> To unsubscribe, send any mail to "freebsd-git-unsubscribe at freebsd.org"
>