Service disruption: git converter currently down

Warner Losh imp at
Tue Oct 1 14:32:05 UTC 2019

On Tue, Oct 1, 2019 at 7:39 AM Ed Maste <emaste at> wrote:

> On Mon, 30 Sep 2019 at 15:17, 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.
> Thanks Ryan. So that can be used to trivially accommodate changed
> hashes in a merge-workflow long-lived downstream project (with the
> downside that two copies of every commit after the divergence will
> appear in vanilla `git log`).

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

For a rebase-workflow branch `git rebase --onto` can be used to move
> commits across a set of changed hashes. For example, assuming we have
> a branch with commits on top of on origin/master they can be moved to
> origin/svn_head via:
> 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. And while it's often convenient to do this, if
the new changes have merge conflicts, then you have to cope with those or
abort the rebase. If you are looking for something that's an exact leap
sidewise, it's less trivial to do. And while many people may be able to
make the jump forward, we need to have a good story for those that can't.
it can be scripted, I'm sure, and we should provide those scripts.

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.


More information about the freebsd-git mailing list