Service disruption: git converter currently down

[Warner Losh]

On Tue, Sep 24, 2019 at 7:48 AM Ed Maste <emaste at freebsd.org> wrote:

> On Mon, 23 Sep 2019 at 13:51, Sean Chittenden <sean at chittenden.org> wrote:
> >
> > >
> > > 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).
> > >
> > 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.
>
> Unfortunately it's not just a few instances of bogus metadata (commit
> timestamps and authors), there are also a cases where the git
> conversion misrepresents the operation performed and makes for
> confusing history.
>

I'm not sure it's completely wrong... I will absolutely agree, however it's
confusing.

One example of this is r306097 / df422cbea30e. A file that had been
> removed in head needed to be restored, and in SVN it was done by
> copying from the stable/10 branch. The git converter interpreted that
> as a merge, and then grafted the post-branch stable/10 history into
> head as a result. That is why we have a bit over 9000 stable/10
> commits showing up in 'git log origin/master'.
>

git log --first-parent fixes that, however.  Git log's notion of what's
sensible to display by default is a poor match to what most people think is
sensible. It is a common thing to have to do with other upstreams I track.
qemu has this same issue because it merges to the mainline. It's the main
reason that I think merge commits to master are evil in a project like
ours. It was the best trick I learned when rebasing our sbruno's
qemu-bsd-user branch to a 3.1 base.

But this really was a merge from stable/10 into master, so we run afoul of
a confusing git log default. We did copy the file from stable/10, though in
a more ideal world this would be represented as a cherry-pick. git doesn't
preserve meta-data for that operation, though (except it can add a note to
the commit message that's free form). So representing it as a merge is
likely the least worst thing it can do to preserve the metadata (although
some would argue that the 'guess about copies' code obviates the need for
keeping this data around).

I'd offer the opinion that needing to know about things like git log
--first-parent vs having to rebase every single downstream fork, the former
is several orders of magnitude less pain. We can ensure that there are no
back doors by doing a diff at a known good version, seeing know differences
with the svn repo and signing the next commit (since it implicitly signs
all previous ones), but that is tricky in a dual world and may need to be
reserved for the svn read-only flag day that we all know is coming.

Warner