Git rebase/merge branch with many moved files and folders

Question

I have a Git repository with two main branches: master and dev. It currently looks like this:

master  ( )----( )----(A)----(B)----(C)
                \
                 \
dev              ( )----( )----( )----( )----(~ 30 additional commits...)

Pretty simple, except that commit A on master contains a major change to the file and folder structure (basically, I used the steps shown here to move the repository up one level in the hierarchy).

I would like to resume work on the dev branch, but when I tried to rebase dev onto master to bring the new file structure into dev, Git spewed a ton of errors. I git reset my way back to a sane state, but in my (somewhat limited) experience with Git, that many errors usually means that I was taking the wrong approach.

Is there a better way to get the reorganized folder structure over to the dev branch? If it helps, the changes in the other commits on master (B and C) are pretty minor and I would be OK with losing them if it would make things easier.

Answer 1

Yes, there is a sane way to do this.

Preface

master is now (if I understood correctly):

project
   src
     file.c

dev is, since it did not contain commit A:

src
  file.c         # with some changes

Your branches are like this:

master  ( )----(A0)----(A)----(B)----(C)
                \
                 \
dev              (D1)----(D2)----(D3)----( )----(~ 30 additional commits...)

I also assume that A differs from A0 in no way whatsoever, except project/ being inserted into all file paths ("moving your tree up" into the new project root, as per your linked question).

Let's do it...

We do exactly what git rebase would do internally, while fooling git a bit, on every step, by doing our own "cherry-pick" step instead of what git would do itself.

We use a second working directory. $WD1 is the absolute path to your original working directory, $WD2 is some other absolute path (outside of that).

First, create your helper directory as a clone of your original:

cd $WD2
git clone $WD1 dev .

Then, start a branch newdev which will eventually be dev rebased on A.

cd $WD1
git checkout A
git checkout -b newdev

We get the D1 commit into newdev without giving git any chance to mess it up:

cd $WD2
git checkout D1

cd $WD1
rm -r project/src
cp -r $WD2/src project/
git add -A
git commit -m "`cd $WD2 ; git log -1 --format=%s`"

The situation is now:

newdev                       (D1')     
                           /
                         /
master  ( )----(A0)----(A)----(B)----(C)
                \
                 \
dev              (D1)----(D2)----(D3)----( )----(~ 30 additional commits...)

Now, repeat for D2:

cd $WD2
git checkout D2

cd $WD1
rm -r project/src
cp -r $WD2/src project/
git add -A
git commit -m "`cd $WD2 ; git log -1 --format=%s`"

The situation is now:

newdev                       (D1')----(D2')     
                           /
                         /
master  ( )----(A0)----(A)----(B)----(C)
                \
                 \
dev              (D1)----(D2)----(D3)----( )----(~ 30 additional commits...)

Repeat until finished.

Of course, you will want to create a small shell script for those commands, which iterates through all commits D1 ... D30.

Afterwards, a simple git rebase master will do the rebase from A to C as usual. Then, get rid of newdev by changing the name around:

git checkout newdev
git branch olddev dev         # just in case...
git branch -D dev
git checkout -b dev

General notes

Why the second working directory?

Note that in this particular case there might be ways to avoid the secondary working directory, by using rm -r project/src ; git checkout D1 src ; mv src project/ directly. I prefer to do it as shown above instead, just to be 100% sure everything is very clean and "visible" at all times. This way the checkout operation is cleanly separated from the modification that we apply on our own.

There is literally nothing that could go wrong this way, and the approach works with all other kinds of changes as well. For a non-trivial change, assume somebody changed every whitespace in every single source file in A. This approach makes it trivial to rebase other branches onto this (if you can put that whitespace change into a script as well).