Re: fuzzy patch application

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 10, 2017, 22:31 UTC
Message-ID: <xmqqy3xdisos.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170210214850.2ok62xdmemgotwnt@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> I dunno. I always use it, but I'm not sure if there are any downsides,
> aside from a little extra processing time. It does have some
> incompatibilities with other options. And I think it kicks in rename
> detection (but I might be mis-remembering another feature). That could
> be surprising, I guess.
>
> The original dates all the way back to 47f0b6d5d (Fall back to three-way
> merge when applying a patch., 2005-10-06), but I don't see any rationale
> for not making it the default. Junio probably could give a better
> answer.

Nothing deep. Just being cautious by not to enable extra frills by default, making it strictly o-p-t i-n. As that was a strict fall back (i.e. there was no "if we are going to fall back, we need to spend extra cycles to do this extra preparation before we attempt the regular application"), extra-processing cost was not a concern, at least back I wrote it the first time. I do not offhand know if that still holds in the current one that was rewritten in C.

Making "am -3" default may also scare users who are not exactly comfortable with reading "git diff" output during a conflicted merge and resolving a conflict, but other than that there shouldn't be any downside.