Hi Eckhard, On Mon, Apr 30, 2018 at 1:03 AM, Eckhard Maaß <eckhard.s.maass@xxxxxxxxxxxxxx> wrote: > On Fri, Apr 27, 2018 at 01:23:20PM -0700, Elijah Newren wrote: >> I doubt it has ever been discussed before this thread. But, if you're >> curious, I'll try to dump a few thoughts. > > Thank you, I try to dump some of mine, too. Maybe let me first stress > that for me copy detection without --find-copies-harder is much more a > "find content extracted" (like methods being factored out). In a way > this is nearer to a rename than to a real copy. Ooh, if you wanted to detect movement of code between files (as blame does, I think searches for PICKAXE_BLAME_MOVE would point you in the right direction) and then try to use that during merge to allow applied changes to move with the code, that would be awesome. Expensive, and might be a lot of work to wire it all up, but it'd be very interesting. I was only discussing DIFF_DETECT_COPY in my previous email, which was all about duplicating entire files; that's something I don't see utility in right now for resolving merges. <snip> > I admit that a "real" copy would get unnoticed that way. But the > semantics of such a copy isn't too clear for me either - did I copy the > other part to make it independent of the other or did I just employ a > copy and paste tactic? The former does not want the changes, the later > does. But I am happy catering to the former here. Right, if you have to assume that the copy was made to make the code independent, then there's no value for merge resolution to having detected the copy in the first place. That has the advantage of side-stepping the possible new edge and corner cases I mentioned in the rest of my email, but it means we shouldn't even spend time detecting copies -- whether whole file (via DIFF_DETECT_COPY) or individual lines (via PICKAXE_BLAME_COPY and variants). Elijah
