One thing you can do in this situation is to pass --no-commit
to git merge
, then go through the files you want to change before committing the merge. However, I would recommend merging as normal, and then doing another explicit commit that restores the files you want. Making unnecessary changes to files in the middle of a merge is rarely a good idea, as it can lead to confusing histories. For example, if you "fix" the problem in the middle of a merge, then later on do a log of the file in question, you won't see the fix, as logging a file history often skips merges. Note that with either approach, if your branch is ever merged back into that other branch, that other branch will have the "fix" as well.
That being said, it seems like there is a deeper problem here. If somebody reverted B
, I assume they did so for a reason, and that their changes in C1
depend on that. So do you really want to be merging in C1
without also merging in their revert? Or was the revert a mistake, in which case you need to educate the developer who did it to stop doing such things?