Related to my previous question Git merge conflict upon rebasing adjacent deletion and insertion?

By default, git's merge algorithm can give dangerous/unhelpful suggestions.

For instance, I have sometimes situations, where I want to push some code changes of my local development branch to the master branch, but keep other changes purely local (e.g. debug code that I still need, or unfinished changes that got mangled into the same branch).

Say, there is a commit sequence:

! --- devel~2 = master
program main
end program main

! --- devel~1
program main
    write *, "Some debug output"
end program main

! --- devel = HEAD
program main
    write *, "Some debug output"
    write *, "Some release mode output"
end program main

Now I use git rebase -i master and want to reverse the order of the two changes. Since it affects adjacent hunks, it will create a merge conflict:

program main
<<<<<<< HEAD
=======
program main
    write *, "Some debug output"
    write *, "Some release mode output"
>>>>>>> b6b1ecc... Add debug message
end program main

It does make sense, as the second line could very well be invalid without the first. However, if the two additions are independent, both suggestions made by git are incorrect.

At this point, the best thing I can do is do look at

git log -n 1 -U b6b1ecc

which will show me what part of the change is really wanted. But in real-world scenarios, it typically isn't even obvious, that the suggestion made by git is incorrect and I've ended up pushing an unfinished change to the master branch because of it.

Is there any way to make git give more appropriate merge suggestions? Especially in such a way, that the final state of the file in the devel branch remains unchanged by the rebase.