From: Junio C Hamano <gitster@pobox.com>
To: Pavel Rappo <pavel.rappo@gmail.com>
Cc: Git mailing list <git@vger.kernel.org>
Subject: Re: Determining if a merge was produced automatically
Date: Mon, 01 Jul 2024 08:39:26 -0700 [thread overview]
Message-ID: <xmqqle2lyvdd.fsf@gitster.g> (raw)
In-Reply-To: <CAChcVu=Kwqj7JhXqQW6Ni9+3TdSfdmHfSTJQWm1_uO2kczSm8g@mail.gmail.com> (Pavel Rappo's message of "Sun, 30 Jun 2024 19:06:24 +0100")
Pavel Rappo <pavel.rappo@gmail.com> writes:
> I'm looking for a robust way to determine if a given merge commit
> could've been produced automatically by `git merge`, without any
> manual intervention or tampering, such as:
>
> - resolving conflicts,
> - stopping (`--no-commit`) and modifying,
> - amending the commit.
This fundamentally cannot be done perfectly and it is by design.
The automated merge algorithms, backends, and strategies will
improve over time, so a merge attempted 7 years ago with the
then-current version of Git may have conflicted and required manual
resolution, but a newer Git you use to "look for manual intervention
or tampering" may have improved enough to resolve the same merge
cleanly and automatically. Even if the person who created the merge
originally and you are using with the same version of Git, the former
may be using a custom low-level merge driver to resolve conflicts in
certain types of files better than the barebones textual merge driver,
while you do not have access to the same driver.
So you'd need to tighten the definition a bit more, at bit more like
constraints like "using the same version of Git" and "without any
low-level merge driver customization".
Now, with problem narrowed down a bit with tightened constraints.
> My initial idea was to re-enact the merge. If the merge failed, ...
> My second idea was to use `git show --diff-merges=dense-combined` ...
> My third idea was to use a recently added feature, `git show --remerge-diff`...
The first and the third are equivalent (the latter is an automation
of what the former would do). The --cc output, as you said, is
about showing resolution that is different from any of the parents,
and serves the need quite different from what you are trying to do
(e.g., if the merge was created with "git merge -s ours", there is
nothing _interesting_ in the result from the "--cc"'s point of view),
but it is likely that you are interested in noticing such an unusual
"cauterizing the history" merge.
next prev parent reply other threads:[~2024-07-01 15:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-30 18:06 Determining if a merge was produced automatically Pavel Rappo
[not found] ` <CANiSa6hVbrCpPtBCL_W8+43uWGL0LFJkFhSJYGtfFgxX75zE8w@mail.gmail.com>
2024-07-01 0:45 ` Martin von Zweigbergk
2024-07-01 15:11 ` Elijah Newren
2024-07-01 16:43 ` Pavel Rappo
2024-07-01 11:49 ` Jonathan Nieder
2024-07-01 13:13 ` Pavel Rappo
2024-07-01 15:43 ` Junio C Hamano
2024-07-01 15:39 ` Junio C Hamano [this message]
2024-07-01 16:08 ` Pavel Rappo
2024-07-01 18:16 ` Junio C Hamano
2024-07-01 22:26 ` Pavel Rappo
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=xmqqle2lyvdd.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=pavel.rappo@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).