Elijah Newren <newren@xxxxxxxxx> writes: > As currently implemented, yes. However, I was more concerned the idea > of handling files differently based on whether or not they were > similar, rather than on what the precise definition of "similar" is > for this context. > > As far as the definition of similarity goes, estimate_similarity() is > currently used by rename detection to compare files recorded at > different pathnames. By contrast, in this context, we are comparing > two files which were recorded with the same pathname. That suggests > the heuristic could be a bit different and use more than just > estimate_similarity(). (e.g. "We consider these files similar IF more > than 50% of the lines match OR both files are less than 2K.") Yeah, I think there is similar difference between similarity score that is used by diffcore-rename and dissimilarity score that is used by diffcore-break exactly for that reason. If you start from a 100-line original file and grow it to 100-line one by adding 900 lines, as long as you kept the original 100 lines, it is easier to view the change within the same path as a continued development, instead of saying they are so dissimilar. In any case, I think the way the stage #2 and stage #3 (i.e. ours and theirs) contents are externalized during a conflicted mergy operation should be consistent across edit/edit and add/add conflict, so if we are adding a new way to write out extra temporary files out of these higher stage index entries, it should be made applicable not only to add/add conflict (i.e. there shounld't be a code that says "oh, let's see, this lacks stage #1, so do this different thing"). Personally, I think it is best to leave it all outside of the core and make "git mergetool" to be responsible for the job of externalizing higher stage index entries to temporary working tree files. They already need to do so in order to work with external tools that do not read directly from our index file anyway, no?
