# try the merge; you'll get conflicts on those files
git merge topic
# discard the versions from the topic branch;
# you know you already merged those changes in
# the funny "git checkout commit", so any differences
# are due to changes on master.
git checkout --ours new-file-{1,18}
# now you are free to fix up any real conflicts
# and resolve the merge
git commit
This has the advantage of representing the true history. You had two lines of development (the original topic, and the "squashed" history created for deployment), and the merge shows them coming together and choosing the deployment-side content.
Yeah; I know it sounds evil and this shouldn't be done but why not just make a new branch from the borked master, force push master back to sanity (pre-massive merge), have everyone else cherry pick and push their commits and then just rebase new branch and fix the conflicts in there as you should and merge normally?
Because it's selfish. Your time isn't more valuable than that of the developers already working against that branch (and as stated in the article, there were hundreds). It's your job to merge your changes cleanly.
so git checkout --ours {name_of_file1,name_of_file2,and_so_on}
The {} is standard bash expansion, you can try it like mkdir hello{one,two,three}, so parent poster went with articles use of new-file as the name of the files that were affected.
