Re: Improving auto conflict resolving while merge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]