Service disruption: git converter currently down

[Warner Losh]

Just FYI:

netflix% git subtree -P FreeBSD merge bsdimp-zooty-svn/meta-bump
fatal: refusing to merge unrelated histories
netflix%git subtree -P FreeBSD merge --allow-unrelated-histories
bsdimp-zooty-svn/meta-bump
error: unknown option `allow-unrelated-histories'
...
bsdimp-zooty-svn is a tree that I've been maintaining via git svn. So the
hashes are different, even though the deltas are the same.

I've not tried a simple 'git merge' yet. It does support
--allow-unrelated-histories, but doesn't support the subtree stuff Netflix
needs.

Needless to say, this is not a happy thing...

Warner


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

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