Re: [PATCH] range-diff: optionally include merge commits' diffs in the analysis

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 11, 2024, 00:20 UTC
Message-ID: <xmqqzfm6k4e5.fsf@gitster.g>
In-Reply-To: <CABPp-BEaZXZ2wSfrkkOAX6W9An8MTf-LEVNKvXvRTxyV9XcKcA@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

> That's particularly odd since the first category is the most
> common, and the third (snuck in unrelated changes or "evil changes")
> are the most rare.  Maybe we should just call these "user-modified
> merges" rather than "evil merges"?  Any better suggestions?

It is "evil" in the sense that it makes it really tough for those who dig history to find out what happened later to figure out where the change came from. It could be an attempt to hide a malicious and unrelated change, it could be a resolution for a non-textual conflict, or it could be a "while at it I am fixing an unrelated typo I spotted nearby while resolving this textual conflict".

The change does not have to have an evil intent. It is just something different from and more than what the textual and mechanical merge would produce.

"more than" may give us a hint for what we want to convey in the name, if we were to pick a new name. If a new topic changed a function signature to add one extra parameter, and updated all the callers of the function that existed back when the topic forked, an "evil" merge needs to address the semantic conflicts to do a very similar update to a new call to the function added on the mainline since the topic forked, when the topic is merged back to the mainline. Taken as a whole, the first-parent diff of such a merge will show that a function gained a parameter, and all of its callers have been adjusted for that change. Most of such changes would have come from the side branch, but on top of that, the merge needed to contribute more of the similar changes to callers.