If the destination branch is changed, but the new destination matches (same commit) the previous destination don't unnaprove.
The use-case where this occurs involves splitting a single branch into multiple pull-requests:
feature_1 of (say) 10 commits
git branch feature_1_infrastructure HEAD^7 git branch feature_1_feature HEAD^3 git push origin feature_1_infrastructure feature_1_feature feature_1:feature_1_tests
_tests pull-requests go to different subsets of the team with:
feature_1_infrastructure -> master feature_1_feature -> feature_1_infrastructure feature_1_tests -> feature_1_feature
Thus the pull-requests only include the relevant section of the original
Assuming no-one else touches master
The first pull-request can be merged by fast forward - now
feature_1_infrastructure, and the target of
feature_1_feature, can be changed to
master, and so on down the line. In the end the original
feature_1 branch has landed.
However on each target change the request is unnaproved even though the git tree (graph?) has not changed - only the name of the destination.
Alternatively I could workaround this if unnaprove on destination branch could be disabled separately to added/removed commits as per #11.