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.