Re: [PATCH] merge-recursive: restore accidentally dropped setting of path

On Tue, Jun 4, 2019 at 12:26 AM Elijah Newren wrote: > On Mon, Jun 3, 2019 at 7:30 PM SZEDER Gábor wrote: > > > - filespec_from_entry(&tmp, ci->ren1->src_entry, other_stage); > > > - tmp.path = a->path; > > > > Note that 'tmp.path' used to be set ... > > > > > - > > > prev_path_des

Re: [PATCH] merge-recursive: restore accidentally dropped setting of path

On Tue, Jun 4, 2019 at 6:14 AM SZEDER Gábor wrote: > > On Tue, Jun 04, 2019 at 12:26:14AM -0700, Elijah Newren wrote: > > Of course, this wasn't the only bug; it also showed we had a glaring > > whole in our test coverage -- there's a dearth of tests for rename/add > > conflicts, and in particular

Re: [PATCH] merge-recursive: restore accidentally dropped setting of path

eporting and SZEDER for jumping on and analyzing and > cc'ing me. > > Sorry for the headache folks, Thanks for the tests! > Subject: [PATCH] merge-recursive: restore accidentally dropped setting of path > > In commit 8daec1df03de ("merge-recursive: switch from (oid,mode

Re: [PATCH] merge-recursive: restore accidentally dropped setting of path

bunch more testing. > > Of course, this wasn't the only bug; it also showed we had a glaring > whole in our test coverage -- there's a dearth of tests for rename/add > conflicts, and in particular none involving content merges for the > rename side. So, I created a patch w

[PATCH] merge-recursive: restore accidentally dropped setting of path

e same patch and added a commit message explaining the issue, using a Based-on-patch-by tag for the fix. SZEDER: if you'd like to see this in a different format (maybe I add tests which show the error and then in a separate patch authored by you we introduce your fix?), just let me know. Since