On Fri, Jul 26, 2019 at 12:15 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > > ... > > So, load the index in builtin/merge-recursive.c, reload the in-memory > > index in builtin/stash.c, and modify the t3030 testcase to correctly > > setup the index and make sure that the test fails in the expected way > > (meaning it reports a rename/rename conflict). > > The last paragraph is what describes what this step does. What is > left unsaid is how that small step relates to the change in the > larger picture (including the title). We do want to have a code > that ensures the index has no higher-stage entries and match HEAD > at the beginning of merge_recursive backend (as your lengthy preamble > leading to the paragraph explains), but adding the code to populate > in-core index to two codepaths does not make them check the condition > automatically---it is only half the story, no? Indeed; the other half is the movement of the index==head check in patch 4 so that it happens immediately and ensures we don't run into this problem again. I can add a note to the commit message that the next patch in the series will be taking care of that half of the problem.
