The diff algorithm you use is in effect from when you set the setting, so it will affect whatever operations are in use at the time. Changing the diff algorithm doesn't have any negative effects explicitly: any diff algorithm will produce an equivalent diff, but the question is how easy it is for folks to read. Patience and histogram are usually better, but not always.

The only time you might have a problem is if you're storing diffs in some system or repository (such as files generated by git format-patch), which isn't very common but is used in some Linux distribution packaging workflows. In such a case, if different people use different diff algorithms, you'll see a lot of diff noise as the patches are regenerated between users, even though the diffs are logically equivalent.

If you have such a case, it's better to just force some fixed diff algorithm with your tooling, which is what I've done in the past. That would look like having your tool run git -c diff.algorithm=myers format-patch.

Beyond that case, there's really no harm in changing the diff algorithm if you find you like something other than the default better.

No,

it will not break anything. The diffs are always calculated after the fact. You can either change the diff algorithm permanently via config or temporarily via option flags on the command line.

Git does not store diffs, all history is stored as (full) snapshots of tree objects. A tree always points to full files ("blobs" in Git terminology) or subdirectories (represented by other tree objects).

Looking at the evolution of both histogram and patience diffs, there is no side-effect for past commits.

There are effects only for the git diff command itself (or diff-based operation like log -p).
For instance, a git diff --histogram done before Git 2.1 would trigger too many memory allocation.