如何解决带有移动文件的 git-svn rebase？

Question

I have a problem rebasing my long-lived branch (called 'metrics') onto the latest version of my 'trunk' branch. The goal is to get my changes rebased, and then committed back to SVN.

The rebase has 75 steps right now, and step 40 is applying significant source code changes onto files that were relocated in svn.

Specifically, I made lots of changes to files in /java/**/*.java. Meanwhile, these files were relocated to: /src/main/java/**/*.java.

git status shows:

# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   added by them:      java/StripesResources.properties
.... (many files like this)
#   both deleted:       src/StripesResources.properties
.... (many files like this)
#   added by us:        src/main/java/StripesResources.properties
.... (many files like this)

There are over 900 files in this state, what do I do to merge them? Not all of them have substantial changes.

I tried moving / copying the 'them' versions of the files (my changes) onto the 'us' locations (where they should be), but that didn't seem to work.

Should I use 'git mv' in this case?

Thanks.

Answer 1

This might not the best solution as it involves history revision. You could use git filter-branch to move the 'metrics' branch's /java/**/*.java files into /src/main/java/**/*.java , then conduct the rebase. First, backup your repository. Then try something like this:

git checkout metrics
git filter-branch --index-filter '
    git ls-files -s |
        perl -pe "s{\t/java/\"?}{\t/src/main/java/}" |
        GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info &&
    mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE
' HEAD

That will rewrite your metric branch's history, effectively moving every file whose path begins with /java/ to /src/main/java . If you want just the java files in those paths, modify the perl statement accordingly. Mucking around with git ls-files -s | perl -pe <substitution> git ls-files -s | perl -pe <substitution> at various points in your history will help you determine what you need.

A a Thing That Can Be Done With Git (tm), the above is awfully drastic. All the same, it should solve the file name issue. Having attempted a few long-divergent branch merges before, this particular problem will not be your last. If your workflow generates highly divergent, long-term branches regularly, you might consider changing it.