On Mon, Nov 27, 2017 at 3:39 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Elijah Newren <newren@xxxxxxxxx> writes: > >>> As a fix, this sorely wants something new in t/ directory. >> >> Well, then perhaps I was wrong to submit it independent of my >> directory rename series. As noted in the (very lengthy) extended >> commit message explanation, the assumption the previous code made just >> happened to work ... > > Here is what I wrote in What's cooking draft (which automatically > gets copied to the merge log message and becomes part of release > notes when a topic graduates) for this thing. Am I on the right > track? > > The code internal to the recursive merge strategy was not fully > prepared to see a path that is renamed to try overwriting another > path that is only different in case on case insensitive systems. > This does not matter in the current code, but will start to matter > once the rename detection logic starts taking hints from nearby > paths moving to some directory and moves a path that is otherwise > not changed along with them. Yes, though I have one minor nit: I'd prefer "a new path" to "a path that is otherwise not changed". (Reason for the nit: "Not changed" to me implies the file existed in the merge base and didn't change name on either side of the merge, which in turn implies the directory remains on both sides, which means there was no directory rename. Since directory rename detection is mostly about moving file adds into the right directory, this seemed like the simplest correction. There are also transitive renames, but they're much less common and trying to cover them too might make it even harder to parse.) As a side note, the two sentences are a little bit unwieldy to try to parse. I couldn't come up with any concrete suggestions to improve it, so it's probably fine, but thought I'd mention in case others spot an easy way to simplify it.
