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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Elijah Newren <newren@xxxxxxxxx> 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.






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux