Re: problem with git detecting proper renames
- From
- Kumar Gala <galak@kernel.crashing.org>
- Date
- Nov 29, 2007, 19:32 UTC
- Message-ID
- <AE325F31-6EDD-4A79-B5EF-5F1D4EBCDBDB@kernel.crashing.org>
- In-Reply-To
- <alpine.LFD.0.9999.0711291122050.8458@woody.linux-foundation.org>
On Nov 29, 2007, at 1:27 PM, Linus Torvalds wrote:
Show 31 quoted lines
> > > On Thu, 29 Nov 2007, Kumar Gala wrote: >> >> In the case of multiple identical matches can we look at the file >> name as a >> possible heuristic? > > We already do. But we only do the base-name part and check it for > exactness, since moving across directories is very common, and we > explicitly want to pick up files that have the same base name. > > However, in your case, not only did you have the same content, you > had the > same basename too! So git considered your renames to be totally > identical > wrt scoring with the current heuristics, and just picked one source at > random. > > And the current heuristics don't even have any "if you already found a > rename, avoid picking the same one twice", so it would pick the *same* > source both times, which is why it looked like "two copies and one > delete". > > This is why I'd like to have a real-life example. I can change the > heuristics, and I even know what are likely to be better heuristics, > but I > still want to actually see and play with an example so that when I > send > Junio a patch, I can explain it and say I've tested it with something > real..
Ok, this is a real example from the u-boot tree. If you give me a little while I can point you at a kernel.org git tree that showed this issue.
- k