On Mon, Apr 30, 2018 at 6:11 AM, Ben Peart <peartben@xxxxxxxxx> wrote: > On 4/27/2018 2:19 PM, Elijah Newren wrote: >> >> From: Elijah Newren <newren@xxxxxxxxx> >> >> On Thu, Apr 26, 2018 at 5:54 PM, Ben Peart <peartben@xxxxxxxxx> wrote: >> >>> Can you write the documentation that clearly explains the exact behavior >>> you >>> want? That would kill two birds with one stone... :) >> >> >> Sure, something like the following is what I envision, and I've tried to >> include the suggestion from Junio to document the copy behavior in the >> merge-recursive documentation. >> <snip> > > Thanks Elijah. I've applied this patch and reviewed and tested it. It works > and addresses the concerns around the settings inheritance from > diff.renames. I still _prefer_ the simpler model that doesn't do the > partial inheritance but I can use this model as well. > > I'm unsure on the protocol here. Should I incorporate this patch and submit > a reroll or can it just be applied as is? I suspect you'll want to re-roll anyway, to base your series on en/rename-directory-detection-reboot instead of on master. (Junio plans to merge it down to next, and your series has four different merge conflicts with it.) There are two other loose ends with this series that Junio will need to weigh in on: - I'm obviously a strong proponent of the inherited setting, but Junio may change his mind after reading Dscho's arguments against it (or after reading my arguments for it). - I like the setting as-is, and think we could allow a "copy" setting for merge.renames to specify that the post-merge diffstat should detect copies (not part of your series, but a useful addition I'd like to tackle afterwards). However, Junio had comments in xmqqwox19ohw.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx about merge.renames handling the scoring as well, like -Xfind-renames. Those sound incompatible to me for a single setting, and I'm unsure if Junio would resolve them the way I do or still feels strongly about the scoring.
