From: Junio C Hamano <gitster@pobox•com>
To: "Felipe Gonçalves Assis" <felipeg.assis@gmail•com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx•de>, git@vger•kernel.org
Subject: Re: Custom merge driver with no rename detection
Date: Mon, 15 Feb 2016 03:03:44 -0800 [thread overview]
Message-ID: <xmqqd1ryqlpr.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CALMa68p9jdO63k2NLTUJXyms=Fc+woXx00UXCxzJ5_zV8jO8Rw@mail.gmail.com> ("Felipe Gonçalves Assis"'s message of "Mon, 15 Feb 2016 08:42:34 -0200")
Felipe Gonçalves Assis <felipeg.assis@gmail•com> writes:
> However, if you do find this approach acceptable/desirable
> (rename-threshold > 100%), I can work on the issues pointed out and
> propose a proper patch.
The caller asks diffcore-rename to detect rename, and the algorithm
compares things to come up with a similarity score and match things
up. And you add an option to the rename detection logic to forbid
finding any?
To be bluntly honest, the approach sounds like a crazy talk.
If your goal is not to allow rename detection at all, why not teach
the caller of the diff machinery not to even ask for rename
detection at all? merge-recursive.c has a helper function called
get_renames(), and it calls into the diff machinery passing
DIFF_DETECT_RENAME option. As a dirty hack, I think you would
achieve your desired result if you stop passing that option there.
I called that a "dirty hack", because for the purpose of not
allowing rename detection inside merge-recursive, I think an even
better thing to do is to teach the get_renames() helper to report to
its caller, under your new option, "I found no renames at all"
without doing anything.
It might be just a simple matter of teaching its callers (there
probably are two of them, one between the common ancestor and our
branch and the other between the common ancestor and their branch)
not call the get_renames() helper at all under your new option, but
I didn't check these callers closely.
next prev parent reply other threads:[~2016-02-15 11:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-14 19:51 Custom merge driver with no rename detection Felipe Gonçalves Assis
2016-02-15 5:10 ` Junio C Hamano
2016-02-15 8:06 ` Johannes Schindelin
2016-02-15 9:57 ` Junio C Hamano
2016-02-15 8:06 ` Johannes Schindelin
2016-02-15 10:42 ` Felipe Gonçalves Assis
2016-02-15 11:03 ` Junio C Hamano [this message]
2016-02-16 1:04 ` Felipe Gonçalves Assis
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=xmqqd1ryqlpr.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=felipeg.assis@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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