All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Tao Klerks <tao@klerks.biz>, git <git@vger.kernel.org>
Subject: Re: Unexpected conflict with ort merge strategy?
Date: Thu, 11 Nov 2021 11:41:52 -0800	[thread overview]
Message-ID: <xmqqfss2lbsv.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BFAf+-ULwtd7WowsN2KSeJ0s1ucZZ1QSRYg8J+wM9MrZw@mail.gmail.com> (Elijah Newren's message of "Thu, 11 Nov 2021 09:57:09 -0800")

Elijah Newren <newren@gmail.com> writes:

> TAKEAWAY: Whenever you are dealing with multiple files or directories
> that are near matches, the person doing merges/rebases/whatever really
> does need to be responsible to pay close attention to any such
> files/directories (and this is not new to merge-ort; it has always
> been an issue with merge-recursive as well).

One difference is that merge-recursive has fewer magic heuristics
(for example, it did not have "my neighbours moved, so I should").

Less clever tools may burden the human users with more manual
resolution in more cases, but when the heuristics work against the
human user, it is easier to understand the situation (iow why/how
the tool made a wrong decision) because they are more predictable.

It is a balancing act.  We would prefer to see things more automated
when there is no room for ambiguity, but a heuristics that works
correctly 80% of the time would force human users to watch out for
mistakes the tool may make in the 20% of the time, which means they
need to look for mistakes in _all_ merges made by the tool, which is
not something we would want.  That is the takeaway.

Thanks.

  reply	other threads:[~2021-11-11 19:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-19 22:40 Unexpected conflict with ort merge strategy? Tao Klerks
2021-11-11 17:57 ` Elijah Newren
2021-11-11 19:41   ` Junio C Hamano [this message]
2022-04-20 11:10   ` Tao Klerks
2022-04-21  3:21     ` 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=xmqqfss2lbsv.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=tao@klerks.biz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.