On 21.06.24 12:19, Phillip Wood wrote: > On 21/06/2024 07:33, Stefan Haller wrote: > >> I'd be interested in example scenarios where both sides of the merge >> have non-empty diffs. Won't this only happen for evil merges? > > I think you'd need a conflicting merge that is resolved in a way that > the resolution of the conflicting lines doesn't match either parent. (I > assume that's what you mean by evil but I thought it best to check) Ah yes, that's another example, but it's not an evil merge. An evil merge is one that has additional changes that don't come from either side, and don't come from conflict resolution (e.g. they were amended into the merge). I thought that was commonly understood terminology. >> This seems unnecessarily restrictive to me. Cherry-picking merge commits >> using -m1 is useful, it's an important part of our release workflow at >> my day job. > > I can see why people want to revert merges but cherry-picking them > always feels strange to me - what is the advantage over actually merging > the branch and seeing the full history of that commit? It's less work (if you otherwise insist on rebasing the branch to the destination before merging), and results in a simpler graph that's easier to understand (if you don't). And I suppose you could ask the same question about the --squash option of git-merge. -Stefan
