Service disruption: git converter currently down

[Ed Maste]

On Tue, 1 Oct 2019 at 10:32, Warner Losh <imp at bsdimp.com> wrote:
>
> I'm pretty sure you'd need to merge to the same svn rev in the new-hash branch as your last merge point, though. I need to test that, though. Usually a merge is to the top of the thing you are merging, so some caution is needed. And all the -s does is accept all our 'conflicts'....

Yes, I've been assuming (and my experiments have been) with an
up-to-date origin/master already merged into my working tree, and an
up-to-date svn_head that exactly matches origin/master.

There are a few different ways this could be done in a
non-experimental situation, and we should experiment with various ones
before anything is finalized.

>> git rebase --onto origin/svn_head origin/master
>
> kinda. It would rebase the current branch onto the new tip of svn_head, not the current branch point. This isn't quite what you want in many cases because it will pull in new changes. The --onto arg needs to be the same svn rev in the new-stream as the current common ancestor of the current branch and origin/master.

Indeed - in my experiments they are one and the same - there are no
new changes in origin/master that are not yet in my working tree.

I guess the rule of thumb should be that work to address changed
upstream hashes should not involve any new changes, and thus cannot
have any conflicts. In my experiments that's most easily achieved by
starting with everything up-to-date.

> So for a single tree, with a single branch, I'll grant trivial. I have 3 or 4 trees now with a total of about 100 branches in various stages of WIPness. For that, it's not at all trivial because maybe 10 of the WIP trees haven't been merged forward in a while due to conflicts that I've not had time to resolve.

I'll grant you even a trivial action multiplied by 100 could extend to
a reasonable effort :)

However, in any scenario you're going to have significant effort to
deal with those 10 WIP trees. If we published both "old" and "new"
versions of the conversion for some reasonable period you can choose
when you spend the time to update those trees, and then perform the
(individually) trivial migration to the new view.