Date: Wed, 23 Dec 2020 16:39:39 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@freebsd.org> To: Renato Botelho <garga@freebsd.org> Cc: Shawn Webb <shawn.webb@hardenedbsd.org>, freebsd-git@freebsd.org Subject: Re: Migrating a merge based project to new tree Message-ID: <X%2BNku/UFku2sr4ZO@acme.spoerlein.net> In-Reply-To: <c852b68a-aa6f-3088-50df-ac97436c711e@FreeBSD.org> References: <fe17e435-0fdb-7529-c04d-2088139d1f14@FreeBSD.org> <20201223141517.xk66q3fboch6fwhj@mutt-hbsd> <c852b68a-aa6f-3088-50df-ac97436c711e@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X%2BNku/UFku2sr4ZO>