In getting a copy of the code and making local changes to it, you have effectively branched it. Meanwhile, back on the main line other changes have taken place and a 2.0 version has been released.

Note that these #1, #2, #3 do not need to match up, nor are they the same feature - just a representation of several changes that have been made to each codeline.
This is what it looks like now, and you are trying to make that merged 2.0
point.
Just doing a diff of the code at Your change #3
and version 2.0
will show you what has changed between the two, but it doesn't show how that fits in. Unless you have marked your code somehow, you will have difficulty determining if the difference between your change #3
and version 2.0
is changes that new features in the mainline, or changes you did in your branch.
For this, you need to use diff3 that that implements a three way merge of the your code, the oldest code, and their code. This takes the version 1.0
as a change.
The man pages for diff3
on developer.apple.com and opendiff
on developer.apple.com (you can also use FileMerge on the mac - remember to expand the window for the 3 way diff. See also How do you do a 3-way merge in FileMerge? - you may also find p4merge from perforce to be to your liking).
Merging an entire major upgrade may be a significant undertaking. I can't say how much has changed in the mainline between version 1.0
and version 2.0
. Long term, you should consider using git, forking the repo and then consistently doing pulls of changes into your branch. This is covered under pull in upstream changes in the git fork a repo article. Doing this for smaller changes will help you keep your code up to date and also reduce the workload compared to major changes. It will also keep you up to date if there are major sections being reworked that you have changes in so that you are aware you will need to budget time there to reintroduce your changes.