git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	 Johannes Sixt <j6t@kdbg.org>,
	 git@vger.kernel.org,
	 Philippe Blain <levraiphilippeblain@gmail.com>,
	 Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>
Subject: Re: [PATCH] range-diff: optionally include merge commits' diffs in the analysis
Date: Mon, 11 Nov 2024 09:20:18 +0900	[thread overview]
Message-ID: <xmqqzfm6k4e5.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BEaZXZ2wSfrkkOAX6W9An8MTf-LEVNKvXvRTxyV9XcKcA@mail.gmail.com> (Elijah Newren's message of "Sat, 9 Nov 2024 00:49:54 -0800")

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.



  reply	other threads:[~2024-11-11  0:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07 17:20 [PATCH] range-diff: optionally include merge commits' diffs in the analysis Johannes Schindelin via GitGitGadget
2024-11-08  3:46 ` Junio C Hamano
2024-11-08  6:53 ` Johannes Sixt
2024-11-08 10:53   ` Johannes Schindelin
2024-11-09  8:49     ` Elijah Newren
2024-11-11  0:20       ` Junio C Hamano [this message]
2024-11-08 11:56   ` Junio C Hamano
2024-11-08 15:53   ` Elijah Newren
2024-11-08 13:43 ` [PATCH v2] " Johannes Schindelin via GitGitGadget
2024-11-08 17:04   ` Elijah Newren
2024-11-11 19:55     ` Johannes Schindelin
2024-11-10 20:30   ` Philippe Blain
2024-11-11 20:07     ` Johannes Schindelin
2024-11-26  7:58       ` Junio C Hamano
2024-11-11  0:37   ` Junio C Hamano
2024-11-11 16:51     ` Elijah Newren
2024-11-12  0:29       ` Junio C Hamano
2024-12-16 14:11   ` [PATCH v3 0/2] Support diff merges option in range diff Johannes Schindelin via GitGitGadget
2024-12-16 14:11     ` [PATCH v3 1/2] range-diff: optionally include merge commits' diffs in the analysis Johannes Schindelin via GitGitGadget
2024-12-16 14:11     ` [PATCH v3 2/2] range-diff: introduce the convenience option `--remerge-diff` Johannes Schindelin via GitGitGadget
2024-11-08 15:33 ` [PATCH] range-diff: optionally include merge commits' diffs in the analysis Elijah Newren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqzfm6k4e5.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=j6t@kdbg.org \
    --cc=levraiphilippeblain@gmail.com \
    --cc=newren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).