Re: Improving auto conflict resolving while merge

From: Jeff King <peff@peff.net>
Date: Sep 8, 2015, 22:03 UTC
Message-ID: <20150908220357.GD24159@sigill.intra.peff.net>
In-Reply-To: <1059528292.20150908210809@yandex.ru>

On Tue, Sep 08, 2015 at 09:08:09PM -0300, Eugen Konkov wrote:

Show 8 quoted lines

> JK> you _could_ argue that those changes are independent But it's close 
> JK> enough that there's a good chance the two need to be reconciled, 
> JK> and a human should at least take a look.
> 
> You are right and your words make sense. But this thought may apply
> for this: We have one method/function about 200 lines. One author make
> change at line 1 of this method and other on 199 line. Both changes
> are done in one method so **human should at least take a look**

Right, there is definitely a concept of "close enough" here, and git cannot catch everything. Semantic changes may even happen across files (e.g., function interface changes). So you do need to rely on things like testing and compilation to verify a merge result.

But I would agree there is room for being able to tune the "closeness" of changes that cause a conflict. Right now that isn't implemented, and I'm not familiar enough with the xdiff merge code to even point you in the right direction.

-Peff