0

Some context, I am trying to rebase my branch off master. But there were some changes done on master that delete a large portion of the code base (this is fine and was expected and talked about). Now I am rebasing my changes off master but I am getting an insane amount of file conflicts that say CONFLICT (modify/delete): someFile.fileType deleted in HEAD and modified in added commitName. Version added commitName of someFile.fileType left in tree. Doing things manually for like 10 files is fine but I have over 1000 of these files. How can I git rm these files and continue rebasing?

Some extra info: I ran the following command git rebase master

Darly
  • 186
  • 2
  • 8
  • My question is: why did those files change on your copy? Is "your branch" a single commit or actually a "real" branch having lots of small commits? Do the conflicting commits have changes in other files then the conflicting? – Timothy Truckle Jun 09 '18 at 08:57

2 Answers2

1

The method is simple enough, but the application of this method requires some care, as it can produce terrible results easily. What you need to do is to identify which files exist at which stage(s) in the index, and then update the index accordingly.

As you said, you have a:

CONFLICT (modify/delete): someFile.fileType deleted in HEAD and modified in ...

Hence you will have a file that exists in the base commit (at stage 1 in the index), and exists in the other commit (stage 3 in the index), but not in the HEAD commit (stage 2 in the index). That file will also exist in the work-tree.

To find out which files are in the index, under which stages, run git ls-files --stage. You then need to alter the index contents to resolve any conflicts and determine what will be committed. If you wish to resolve this conflict by removing the file in the final commit, you can simply run git rm someFile.fileType, which will remove all of the index entries and the work-tree version of the file as well.

Hence, as a very cheat-y method, this could work:

git ls-files --stage | awk $'/ 3\t/ { print $4 }' | xargs git rm

Be very careful with this! If you blindly apply some recipe you don't understand, you may bake a poisonous cake. Note that this totally ignores whether the same file has a stage-2 entry, and looks only for a stage-3 entry in the index. It also misbehaves for any path name that has whitespace in it, since awk is field-separating by whitespace here.

Note that all resolved files are in the index as stage zero, so if you have any conflicts other than the modify/delete ones, you can resolve them manually first, then use the above command to git rm the remaining ones.

torek
  • 330,127
  • 43
  • 437
  • 552
1

Mass retroactive just-about-anything is a job for git filter-branch.

git diff --name-only --diff-filter=D  ...master

will generate a list of all files that were deleted from the master since you branched.

wipelist=`mktemp`
git checkout -b WIP
git diff  --name-only  --diff-filter=D   ...master    >$wipelist
git filter-branch --prune-empty --index-filter "
                git update-index --force-remove --stdin  <$wipelist
        " -- master..

Now you have a WIP branch that's exactly like whatever was checked out before, except nothing on it has any of the files that no longer exist on the master branch, the very first commit on WIP deletes everything subsequently deleted on master.

jthill
  • 42,819
  • 4
  • 65
  • 113