On Fri, May 24 2019, Robert Dailey 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? We don't have a merge strategy to do this, but should. I had a WIP patch for this here that I haven't picked up: https://public-inbox.org/git/87sh7sdtc1.fsf@xxxxxxxxxxxxxxxxxxx/ But you can emulate the same thing with "read-tree" and "commit". I.e. manually craft a commit with plumbing that diverges from the "master" branch, then instead of stock "rebase" write some loop where you keep using "read-tree" to read what you want to stage into the index from the existing branched commits, then the equivalent of "git commit -c" etc. to commit it.
