git merge or cherry-pick for copying commits from old branch into newer branch?

Question

The previous guy had worked on local clone of LO(LibreOffice) for TB_LR script support during 2015, and now my job is to get all his commits on his branch to reproduce his work on current LO clone. I was told to cherry-pick his commit one by one, resolve conflicts, build, fix compile and link errors, then repeat the same steps for remaining commits.

I cloned LO, made a new branch, CP-ed his first 10 commits (first 9 CP were finished without build errors one by one), and that 10th commit is a huge commit with lots of files changed, then I ran into the following error:

[build OCC] apple_remote/source/RemoteMainController.m
make[1]: * ** No rule to make target '/Users/almas/lode/dev/core/vcl/vcl.common.component', needed by '/Users/almas/lode/dev/core/workdir/ComponentTarget/vcl/vcl.common.component'.
Stop.
make[1]: * ** Waiting for unfinished jobs....
Makefile:276: recipe for target 'build' failed
make: * ** [build] Error 2

I did "git diff origin/master -- makefiles" for Makefile, Makefile.gbuild, vcl/Makefile and apple_remote/Makefile, all the same with origin/master.

I don't know how to solve this error and proceed. I'm stuck.

Furthermore, I still have about 40 commits of his 2015's branch to incorporate into newer LO source for my job.

Is making a copy of his 2015's branch, doing "git merge master", then resolving conflicts, the best way for adding all his work into my newer LO clone?
Or merging his 2015's branch into my newer LO clone? (git checkout master && git merge his_2015's_branch)

Whichever way and no matter what will happen during those 2 merges, the current status of my work branch isn't going to be affected, right?

I can always get back to the current branch's "No rule to make targe" status even if merge errors or conflicts happen on 2 other branches, isn't it?

Do I need to make a copy of $LODE_HOME/dev/core directory which is significantly large, in case merge goes wrong?

Answer 1

How many changes have happened to LibreOffice in those 3 years? Git isn't magic, there is no combination of commands that can resolve merge conflicts. You have to understand the code.

In the case of an old branch like this, I would recommend simply making a new branch and manually redoing the work.

You can do a source code compare with the final state of the old branch, presumably there are whole new files which you can reuse with minimal changes.

But it generally it will be easier to write the functions from scratch on the current base than try to understand the evolution of the code over those three years and what the merge code should look like on each commit.