Re: [PATCH 1/3] t7405: add a file/submodule conflict

[Elijah Newren <newren@gmail.com>]

On Tue, Jul 10, 2018 at 8:53 AM, Stefan Beller <sbeller@google.com> wrote:
> On Tue, Jul 10, 2018 at 8:28 AM Elijah Newren <newren@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

:-)