# Re: [PATCH] array index mixup

1 messages from 2006-07-16 to 2006-07-16. Participants: linux@horizon.com.
Thread: https://gitlist.dev/t/4903

## linux@horizon.com, 2006-07-16 18:12

Subject: Re: [PATCH] array index mixup
Message-ID: <20060716181228.25231.qmail@science.horizon.com>
URL: https://gitlist.dev/e/20060716181228.25231.qmail%40science.horizon.com

```
> *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.

```