Re: [PATCH] range-diff: optionally include merge commits' diffs in the analysis
- From
Elijah Newren <newren@gmail.com>
- Date
- Nov 9, 2024, 08:49 UTC
- Message-ID
- <CABPp-BEaZXZ2wSfrkkOAX6W9An8MTf-LEVNKvXvRTxyV9XcKcA@mail.gmail.com>
- In-Reply-To
- <af576487-5de2-fba3-b341-3c082322c9ec@gmx.de>
One more thing...
On Fri, Nov 8, 2024 at 3:04 AM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
[...]
> Footnote *1*: We should really find a much better name for this than "evil > merge". There is nothing evil about me having to add `#include > "environment.h"` in v2.45.1^, for example. It was necessary so that the > code would build. Tedious, yes, but not evil.
Indeed, I've felt it's problematic for a while too and had to take time on at least one occasion to mention to someone else that I don't actually mean "evil" it's just that "evil merge" as a compound term is the convenient nomenclature we've been using for all of these, regardless of whether the user modified the merge to resolve syntactic conflicts, or to resolve semantic conflicts, or to sneak in "evil" changes. 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?