Re: [PATCH] array index mixup
- From
- linux@horizon.com <linux@horizon.com>
- Date
- Jul 16, 2006, 18:12 UTC
- Message-ID
- <20060716181228.25231.qmail@science.horizon.com>
Show 9 quoted lines
> *1* If somebody wants to do this, one thing to watch out for is > matching up of broken pairs. If a pair originally broken by > diffcore-break (because they were dissimilar enough according to > the option given to -B flag) are merged into one by > diffcore-rename (because they were similar enough according to > the option given to -M flag), we should _not_ say the resulting > pair is renamed. In general, the threashold for breaking should > be lower than diffcore-rename to merge them for a sane use, so > this might be a non-issue in practice, though.
Er... no. You want to be fairly aggressive when doing both things. That is, you want to break aggressively so you can look for a better match elsewhere, but once you've found the best match, you don't want to be shy about accepting it.
Pulling numbers out of thin air, say break if 1/3 of a file has changed (66% common), and merge if you have 33% common. Or maybe even less. The point of break then merge is to give you a chance to find the 90% common file that has a new name.
I always understood that the reason for having two thresholds is exactly so they can have this relationship, not the opposite one as you suggest.