Junio C Hamano <gitster@xxxxxxxxx> writes: > Elijah Newren <newren@xxxxxxxxx> writes: > >> It does sound potentially expensive, though, and might mean a lot >> more work in merge-recursive to handle that extra information. Is that a >> path we want to take at some point? > > Probably you can start with backend specific option (e.g. -Xbreak=yes) to > experiment. We made recursive the default not because it deals with > renames (in a broken way) but primarily because it handles criss-cross > better; at some point we might also want to add another backend specific > option (e.g. -Xrename=off) to allow the users to keep the "recursive" > aspect of the strategy while declining a more expensive (and brittle) > rename handling to take effect. > > My gut feeling is that -Xbreak=yes, once the code does work well enough, > would have to become the default. It would make the default mode of merge > possibly quite expensive but it is Ok as long as we give projects with > simple/clean history an easy way to use either "recursive -Xrename=off" or > even "resolve" to avoid cost that is unnecessary to handle their needs. I forgot to mention that there is jk/maint-merge-rename-create effort by Peff already queued in 'pu' to use "break", which of course has unfortunate conflicts with your series. -- 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