On Tue, Jul 10, 2018 at 8:53 AM, Stefan Beller <sbel...@google.com> wrote: > On Tue, Jul 10, 2018 at 8:28 AM Elijah Newren <new...@gmail.com> wrote:
>> 2) I didn't just check what was currently failing but other things >> that should be true for this test. >> >> For item 2, I've had multiple cases in the past where I created a >> minimal test, only to find that if I had more carefully checked the >> expected results that it would have prevented a future bug. Also, it >> was harder in the future to figure out, because I no longer remembered >> the context for the test setup. So, in this test I check the contents >> of the index, make sure that the submodule is still present, and then >> I finally check for the thing that currently fails: >> >> commit B added a file called 'path'; its contents should appear >> somewhere in the directory for the user to use when trying to resolve >> the failed merge. It cannot appear at 'path' (there's a submodule in >> the way from commit A), but it should be present somewhere, and in >> particular I'd expect it in the same directory. So, I simply grep all >> files in the current directory for the string (and ignore errors about >> 'grep: path is a directory'). >> >> Does that help? If so, I'll submit a reroll with the changes and a >> few extra comments. > > That does help; yes, I thought > * we want to check for the file content of the file to be somewhere > (maybe path.file?) Yes. I wanted to avoid nailing down the expected pathname until the code was in place that handled this case. merge-recursive currently elsewhere uses path~$BRANCH to workaround conflicting paths, but I had a (half-baked-so-far) idea for changing some of the path-conflict stuff which would involve different names. So, I just left it undecided until implemented. > * equally we'd want to have the submodule somewhere; you seem > to expect it at path (we could have moved it to path.sub or path.git, > but that involves extra work as we have to update the .gitmodules > file to have the correct path <->name mapping) Yes I wanted it at path for a specific reason: git can detect renames of files, and now of directories, but not of submodules, so it seems more important to keep the submodule where it is when possible. (merge_file_1() has code running counter to this, but that pre-dates submodules and should be updated, IMO.) > * good call with the index, I skimmed over the ls-files calls not thinking > what they'd check. > > So for now only the "file content is missing" part is failing the test, > whereas the rest is successful. > > Thanks for the explanation! > Stefan :-)
