Service disruption: git converter currently down

[Shawn Webb]

Hey Ulrich,

I appreciate your hard work in maintaining the git mirror. Work like
this can sometimes go unthanked. I want to take a moment to show
appreciation for you and the FreeBSD project in maintaining the git
mirror.

I do have a few concerns with what was stated in your email. I've
written my concerns inline. I hope this discussion is a positive one,
wherein upstream and downstream can effectively come to a conclusion.

On Mon, Sep 23, 2019 at 08:16:25PM +0200, Ulrich Sp??rlein 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

Such a workflow breaks historical accuracy. Instead of `git annotate`
showing the history properly, it's now based on an "epoch commit".
Sure such a commit brings the branch to a working condition, but at
the cost of history.

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

I so wish that were possible for certain downstream projects. We're
unable to upstream the majority of our work. To argue "upstream your
work and you won't be affected" is to choose an argument that does not
reflect the reality of a growing portion of FreeBSD's downstream
consumers: the inability to work effectively with upstream.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-git/attachments/20190923/6feec63a/attachment.sig>