Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> 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? You probably wouldn't be asking that if you read what you cut out when you quoted above ;-) There are a collection of cherry-pickable commits in hierarchy under refs/merge-fix. They are indexed by the branch that will cause semantic conflicts that do not involve textual conflicts at all (the important implication of which is that 'rerere' fundamentally will not trigger to help resolving them) [*1*], and are used to create evil merge when a corresponding branch is merged to 'pu' (and down). [Footnote] *1* One topic adds an extra parameter to read_index_from() that has been and still is defined in a file and merged to 'pu' first, while another topic adds a new callsite for the same function in a file that the former topic does not touch, hence a merge of the latter topic has no textual conflict to the file with a new callsite, but still needs adjusting. That sort of think.
