Service disruption: git converter currently down

Warner Losh imp at
Tue Oct 1 14:22:09 UTC 2019

On Mon, Sep 30, 2019 at 1:17 PM Ryan Stone <rysto32 at> wrote:

> On Thu, Sep 26, 2019 at 10:27 AM Ed Maste <emaste at> wrote:
> > If you try this in a tree with changes (i.e., try applying it to a
> > long-running merge-based branch) every modified file will result in a
> > conflict, but they can be trivially resolved in favour of the first
> > version. From that point on merging from the "new" conversion will
> > work as expected.
> You don't have to do this manually.  "git merge -s ours
> origin/svn_head" will record a merge but will not make any changes to
> the local tree.

I'm confused by this. origin/svn_head points to the tip of svn_head
upstream. This is likely different than the last merge point of ours, so
I'm unclear how this wouldn't bring in extra changes (or blindly say that
those revisions had already been merged). You need to merge in the
origin/newhash tree at the same svn revision as the current tree to do a
zero-change merge. As such, you'd need some automation around this. i've
run afoul of this sort of thing in other projects, and want to make sure
that the issues there don't apply here.

I'll see if this actually works by pushing one of my git svn trees that has
the different hashes to github and trying to merge our work tree to that
instead of the current FreeBSD upstream.


More information about the freebsd-git mailing list