On Fri, May 24, 2019 at 9:04 AM Robert Dailey <rcdailey.lists@xxxxxxxxx> wrote: > > Everything I'm going to describe is related to this repository: > > https://github.com/powervr-graphics/Native_SDK > > This repo has several distinct branches. None of them seem to be tied > to each other. Instead of having a `master` where they branched off > each of their releases (e.g. 3.1, 3.2, 4.0), it looks like they made a > copy of previous branches with no ancestry and then continued coding > on that. > > What I'm trying to do is go back and rebase all of the X.X branches > onto a new `master` branch. I started off with this: > > $ git checkout --orphan master > > Then I committed a `.gitattributes`. Next, I rebased the first > (oldest) release branch: > > $ git rebase -i --onto master origin/3.0 --root > > Then I merged: > > $ git checkout master && git merge --no-ff - > > Next, I did 3.1: > > $ git rebase -i --onto master origin/3.0 origin/3.1 -X theirs > > Using interactive mode, Git is smart enough to detect duplicate > commits and eliminates those, even though the 2 branches do not share > a merge base. I continued doing this all the way up to rebasing 4.3, > but that's when things got tough. I see a lot of 'UD', 'UA', 'AU', > 'AA' merge conflicts. These are obviously due to the fact that the > branches aren't connected. But I expected was that `-X theirs` would > always favor what's on the branch being rebased. However, it seems > this only affects modified conflicts, not adds or deletes. > > I was trying to find a way to bulk-resolve these. I mean, if git sees > a file added on the left AND the right, I want the right one (theirs; > the one coming from the 4.3 branch). Even though the branches are > unrelated in terms of their history, I want the net effect of the > rebase to essentially reflect the files on 4.3 itself. If a file isn't > present on HEAD, delete it. If a file exists on REBASE_HEAD but not on > HEAD, then add it. If the same file exists on both, favor the one on > REBASE_HEAD. > > But I don't see a way of doing that. I tried `git checkout --theirs .` > and `git checkout REBASE_HEAD -- .` but this doesn't work with all > conflict types. > > Can anyone provide some advice on how to properly restructure this > repository to create some ancestry, as if all along a `master` existed > and all release branches were based on this in a linear fashion? By the way, everything I've done so far (up to 4.2) is located here: https://github.com/rcdailey/Native_SDK There is a `master` branch in my fork of that repo. I am not sure if I've done it correctly so far, or if how I've done this up to 4.2 explains why 4.3 is so hard.
