Hi Junio, On Tue, 6 Mar 2018, Junio C Hamano wrote:
> Phillip Wood <phillip.w...@talktalk.net> 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. So essentially, you have something that `git rerere` would have learned, but as a commit? Might make sense to make that procedure more accessible to others, too ;-) I know that *I* would use it. Ciao, Dscho
