Phillip Wood <phillip.wood@xxxxxxxxxxxx> writes: > I wonder if just having a predicable result rather than forcing the > rebase to stop if the user just squashes a fixup commit into a topic > branch that is the parent of a merge might be more convenient in practice. Unless I am misunderstanding what you are saying, that is pretty much what I have automated for my daily rebuild of the 'pu' branch Non-textual semantic conflicts are made (in the best case just once) as a separate commit on top of mechanical auto-merge whose focus is predictability (rather than cleverness) done by Git, and then that separate commit is kept outside the history. When replaying these merges to rebuild the 'pu' branch, after resetting the tip to 'master', each topic is merged mechanically, and if such a fix-up commit is present, "cherry-pick --no-commit" applies it and then "commit --amend --no-edit" to adjust the merge. I find it quite valuable to have a separate record of what "evil" non-mechanical adjustment was done, which I know won't be lost in the noise when these merges need to be redone daily or more often. The Appendix in Documentation/howto/maintain-git.txt talks about this process. You can see what topics have such merge-fix defined by peeking https://github.com/gitster/git/ repository.
