On Mon, Jul 1, 2024 at 7:16 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Pavel Rappo <pavel.rappo@xxxxxxxxx> writes: > > > it for such merge commits produced automatically because of the > > assumption that nothing bad can happen there. > > I do not think that assumption holds in the first place, though. A > typical and often cited example is when one side changed a helper > function's behaviour while the other side added new callers to the > helper function, still assuming the original behaviour. In such a > case there may not even be an textual conflict but the end results > may be broken, and if the breakage is subtle, it may take weeks or > months before somebody notices such a semantic mismerge. Junio, I'm under no illusion that Git can resolve semantic conflicts, such as the one you described. When I said "nothing bad can happen" I didn't mean broken code, I meant unreviewed, possibly malicious changes making their way into the target branch. Suppose, we have the master branch and a PR against that branch. If a new commit is pushed into the PR branch, we want it to be reviewed, unless that commit is a merge from master to the PR branch. In that case, we try to replicate the merge to see if it yields the same result. If the result is the same, we will not require re-review. Why do we not require a re-review in that case? Because when a PR is integrated, it is merged with the master anyway. That merge is unsupervised and unreviewed. If we flip sides, it means that we may want to not require a review for merging from master to the PR. It's this sense that "nothing bad can happen". > But there, you'd need more than "both are cleanly auto-merged"; more > like "both may have conflicted but they are resolved the same way" > is what you are interested, no? Since at that point, your primary > interest shouldn't be "does it cleanly auto-merge?" but "do these > two merges do the same thing?", determining if a merge was created > automatically becomes a problem you do not need to solve, or solving > it would not further your true goal. Automatic merge is just a merge made by git merge or another command that I expect authors to use for occasional merge from master into their PRs. It's not a special merge. It's just a reference merge. Sorry, I'm not good at writing text. I really hope this email clarifies my use case and what I am trying to do about it. > If you have two integration branches A and B, and a topic branch T > first gets merged to A and then after proving its worth it gets > merged down to B, I wonder if you can verify somebody's merge of B > into T by comparing the result with your "verification merge", which > you preform locally and on a throw-away branch by using "git rebase > --rebase-merges" or some mechanism, to replay the original merge of > T into A on top of B (before the merge of T you are verifying). That sounds like my first idea with extra steps; not sure. -Pavel
