Migrating a merge based project to new tree
Ulrich Spörlein
uqs at freebsd.org
Wed Dec 23 15:39:41 UTC 2020
On Wed, 2020-12-23 at 11:29:10 -0300, Renato Botelho wrote:
>On 23/12/20 11:15, Shawn Webb wrote:
>> On Wed, Dec 23, 2020 at 09:35:11AM -0300, Renato Botelho wrote:
>>> I'm working to migrate a downstream stable/12 based tree to the new git
>>> repository following instructions from [1].
>>>
>>> I did a final merge from legacy repository and made sure top commits on both
>>> branches point to the same tree:
>>>
>>> # git show -s --format=%T f4d0bc6aa6b9
>>> 98db7229803a5c93e3132bc661201f204487eee9
>>> # git show -s --format=%T f262e04c92d7
>>> 98db7229803a5c93e3132bc661201f204487eee9
>>>
>>> When I try to merge new one git refuses to merge due to unrelated histories.
>>> Should I use --allow-unrelated-histories parameter?
>>>
>>> [1] https://github.com/freebsd/git_conv/wiki/Migrating-merge-based-project-from-legacy-git-tree
>>
>> HardenedBSD's in the same boat. We're toying around with different
>> methods of fixing our repo right now. When I used
>> --allow-unrelated-histories, git noted merge conflicts on every single
>> file HardenedBSD has touched over the last 7.5 years. I tacked on "-X
>> ours" and that made git happy. However, I'm unsure git always did the
>> right thing. I'm working to verify that this week along with trying
>> the other documented methods.
>
>I've managed to do it adding `-s ours` to change merge strategy and
>preserve our changes.
>
>git merge legacy/stable/12
>git push origin devel-12
>git merge --allow-unrelated-histories -s ours freebsd/stable/12
>
>After that I can confirm there are no differences:
>
># git status
>On branch devel-12
>Your branch is ahead of 'origin/devel-12' by 243035 commits.
> (use "git push" to publish your local commits)
>
># git diff origin/devel-12
>#
Heh, you can simply write out your own commit and give it a number of
parents (any number you like).
Given your example above, you can merge those two commits (with the same
tree, or with a tree from your actual branch) like so:
tree=98db7229803a5c93e3132bc661201f204487eee9
git commit-tree -m "now kiss" -p f4d0bc6aa6b9 -p f262e04c92d7 98db7229803a5c93e3132bc661201f204487eee9
This will spit out a new commit hash, that has the tree of your choosing
as well as those 2 commits as parents. You still need to stick that ref
into something that you can name. Now I never know what git reset does
precisely, but I think you can point your checkout out copy to that
commit with
git reset --hard <hash output from commit-tree>
or you stick it into a brand new ref (also called a branch).
git update-ref refs/heads/my_merge <hash output from commit-tree>
If you can easily rebase your changes, that would be best. If the
changes are scattered throughout the history and upstream was frequently
merged, that doesn't work of course. If you don't need the per-change
history, you can of course extract a patch and apply it to a clean tree,
but that seems a lot of effort when you can craft your own commits with
a one liner and then just need to update a ref to point to it (somehow).
hth
Uli
More information about the freebsd-git
mailing list