Service disruption: git converter currently down

[Ed Maste]

On Tue, 1 Oct 2019 at 10:22, Warner Losh <imp at bsdimp.com> wrote:
>
> On Mon, Sep 30, 2019 at 1:17 PM Ryan Stone <rysto32 at gmail.com> wrote:
>>
>> On Thu, Sep 26, 2019 at 10:27 AM Ed Maste <emaste at freebsd.org> 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.

Yes, you need to already have the "old" version of the same tree
you're going to merge from in place. The full procedure would be
something like:

% git fetch origin
% git diff origin/master origin/svn_head # confirm identical
% git merge origin/master
% git merge -s ours origin/svn_head

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

That'd be great, allowing for experimentation with concrete examples.