Service disruption: git converter currently down

[Ed Maste]

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.

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

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

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.