We have a master branch with several commits:
1 -> 2 -> 3 -> 4 -> 5 -> ..... -> 100
This master was already deployed to production.
Now we discovered that in version 3 a bug was introduced to the system, causing more fixes in versions 10, 15, 34, ... were people try to solve the issue and creating new problems by that.
Since some of the commits are important and since the master was already deployed, we can't just reset back to version 3.
So we created a branch from version 2 (right before the bug) and worked our way to include the relevant features that were committed:
1 -> 2 -> 3 -> 4 -> 5 -> ..... -> 100
\
A -> B -> C ...........- > Z
Now we like to take the Z version and merge / rebase it as our master's newest version.
Again, we like to keep all the history of 3 til 100.
We know that one option is to rebase A on version 100 and another will be to merge Z into 100, but we are not sure what will be a better approach in this case.
Why not record what's really happening? You're abandoning the 3..100 series in favor of the A..Z series, so record that:
git tag -m "3 was so bad we abandoned the branch here" abandoned-master master
git checkout -B master better-version
producing
... 1---2---3 ... 100 abandoned-master
\
A---B ... Z master
and if your production environment keeps sane logs of what commits were put into production, anyone looking at them and at git's history will see exactly what happened: commits 3,10,54,100 were put into production, then Z was put in production. It's absolutely clear what happened here.
Adding lies
# as above, then
git merge -s ours -m "not really a merge, ^2 is abandoned history" master@{1}
... 1---2---3 ... 100 abandoned-master
\ \
A---B...Z---* master
or the rebase, which even more thoroughly misrepresents history, will actively conceal relevant facts. No one using the falsified histories will be helped.