Ah, I should have been more precise. If you were to reword a commit in the equivalent manner as `git rebase -i`, which is to say, reapplying any descendant commits/patches, you would be guaranteed not to get conflicts while applying descendant commits.
I suppose there is some possibility for merge conflicts in a workflow where you reword a public commit, which changes the merge-base in an unfortunate way and causes conflicts to appear which wouldn't have otherwise. Primarily I meant the workflow where you reword local commits only.
More enlightened version control systems like Mercurial can handle this better, such as via its "commit evolution" feature. If you then rebase on top of a reworded commit, the patches will apply the same, and you can resolve the so-called "divergence" by running `hg evolve`. (It's still possible to have un-automatically-remediable divergences, such as if two people reword the same public commit in different ways, but it handles the common case.)
I suppose there is some possibility for merge conflicts in a workflow where you reword a public commit, which changes the merge-base in an unfortunate way and causes conflicts to appear which wouldn't have otherwise. Primarily I meant the workflow where you reword local commits only.
More enlightened version control systems like Mercurial can handle this better, such as via its "commit evolution" feature. If you then rebase on top of a reworded commit, the patches will apply the same, and you can resolve the so-called "divergence" by running `hg evolve`. (It's still possible to have un-automatically-remediable divergences, such as if two people reword the same public commit in different ways, but it handles the common case.)