Service disruption: git converter currently down

[Warner Losh]

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

> On Thu, 26 Sep 2019 at 13:26, Warner Losh <imp at bsdimp.com> wrote:
> >
> > The --first-parent actually mirrors what svn log shows today. What
> commits do you think that it omits?
>
> Right, my comment was in regards to use in my 'wipbsd' merge-based git
> branch. A git merge-based workflow is fundamentally not possible with
> svn, so what svn log can show isn't all that interesting :)
>
> What I mean is that I can either git log without --first-parent, and
> see all changes including the 9000 "phantom" commits, or I can git log
> with --first-parent which excludes those phantom commits, but also
> excludes commits I do want to see because when I merge from
> upstream/master both parents are important - my work, and new upstream
> commits.
>

You do see all the MERGE commits still, though, with --first-parent. you
just don't see all the extra commits they refer to. It excludes the 9000
phantom commits but not the merge point that brings them in. The same would
be true of other upstream merges.


> > I'll have to try that to see how well it works. I'd not used
> allow-unrelated-histories and had frequently run into this issue. In the
> past, I'd been warned off using that flag, but I'll give it another try.
>
> I presume it can cause a lot of grief on truly unrelated trees, but in
> this case we have two trees with no commit objects in common, but in
> fact do have tree objects in common.
>

My experience with rebasing our work qemu bsd-user branch suggests that
even with the 'common ancestor' there's no end of trouble with you
introduce a lot of merges and once you get more than a few hundred (or
maybe a few thousand) commits away from a common ancestor, things break
down and need careful study... When git works, it's awesome, but when it
doesn't, it's a very rough ride and it's fear of that rough ride that has
me asking all the questions and wanting to know the exact details. When
1000 downstream trees convert, we don't want more than a couple of them
having issues or we'll be overwhelmed and we'll risk alienating our users.


> > We basically have an upstream called 'FreeBSD' that we fetch into our
> git repo:
> [omitted]
>
> Thanks, so it's basically a regular merge workflow with the added fun
> of subtrees; some experimentation is going to be necessary here but I
> believe it will be possible to use the same techniques.
>

Right. The proof is in the pudding, as they say.


> Presumably we could publish two ongoing svn2git conversions during an
> overlap period (existing, and corrected), as well as a snapshot of
> merging existing into ng. A one time merge of that (instead of
> FreeBSD/master in your example above)  would bridge the gap to the ng
> conversion.
>

I totally agree. It would be trivial to push master-newhash at any time and
that would be 100% non-disruptive. I'm less optimistic about having a ng
merged thing work, but if it does we can publish.

Is there an easy way for me to run the new conversion script to create a
stream that won't push to FreeBSD's github upstream automatically?

Warner