{"thread":{"id":"4903","subject":"Re: [PATCH] array index mixup","startedAt":"2006-07-16T18:12:28Z","lastAt":"2006-07-16T18:12:28Z","messageCount":1,"participants":["linux@horizon.com"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"23881","messageId":"20060716181228.25231.qmail@science.horizon.com","threadId":"4903","inReplyTo":null,"subject":"Re: [PATCH] array index mixup","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-07-16T18:12:28Z","receivedAt":"2006-07-16T18:12:28Z","isPatch":true,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> *1* If somebody wants to do this, one thing to watch out for is\n> matching up of broken pairs.  If a pair originally broken by\n> diffcore-break (because they were dissimilar enough according to\n> the option given to -B flag) are merged into one by\n> diffcore-rename (because they were similar enough according to\n> the option given to -M flag), we should _not_ say the resulting\n> pair is renamed.  In general, the threashold for breaking should\n> be lower than diffcore-rename to merge them for a sane use, so\n> this might be a non-issue in practice, though.\n\nEr... no.  You want to be fairly aggressive when doing both things.\nThat is, you want to break aggressively so you can look for a better\nmatch elsewhere, but once you've found the best match, you don't want to\nbe shy about accepting it.\n\nPulling numbers out of thin air, say break if 1/3 of a file has\nchanged (66% common), and merge if you have 33% common.  Or maybe\neven less.  The point of break then merge is to give you a chance\nto find the 90% common file that has a new name.\n\nI always understood that the reason for having two thresholds\nis exactly so they can have this relationship, not the opposite\none as you suggest.\n"}]}