Elijah Newren <newren@xxxxxxxxx> writes: > Because it's so hard to rule out regressions with so many changes to a > complicated portion of the code (though hopefully it is less complicated > now), and because we've had multiple problems in the past with the > changes I've been making to merge-recursive, I came up with an idea to > test this series more thoroughly. So, I wrote a script to take every > single merge commit in git.git that had exactly two parents (no octopus > merges) and redid them both with /usr/bin/git and the version of git > from this series. I checked to ensure that the two different versions > of git: > (a) EITHER both failed to merge cleanly OR both merged cleanly > AND > (b) the output of 'git ls-tree -r HEAD' matched between the two > > I ran this process with the original version of the series and indeed > found that my original series mis-merged half a dozen or so merges (out > of about 5000). Thanks for doing this; note that the previous "simple one-side renamed the other just updated in-place are merged incorrectly" was caught by such a test. One thing we may need to be careful about is to compare the conflicted state a failed merge leaves behind. The latter half of (a) together with (b) will ensure that you did not introduce silent mismerges. Avoiding silent mismerges is of course one of the most important criteria, but we also need to make sure that a conflicted state left in the index and the working tree files must not be harder to reconcile than what we have been giving our users---otherwise the change will be seen as a regression by them. > *** What is still missing *** > > Two things: > * Junio had a great suggestion about alternate handling of the index in the > case of rename/rename(2to1) and directory/file conflicts (just rename the > entry in the index to match how we are renaming in the working copy to > some new unique name, in order to allow 'git diff' to provide more useful > information to the user). Just didn't get to it. > * Support for running break detection in diffs, in order to fix the testcase > corrected by Peff in this series. Simply didn't get around to it either. I would say it is sensible to leave these two out. They can be done as a follow-up series after dust settles. Thanks. -- 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