Re: [PATCH 1/3] t7405: add a file/submodule conflict
- Date: Tue, 10 Jul 2018 10:30:13 -0700
- From: Elijah Newren <newren@xxxxxxxxx>
- Subject: Re: [PATCH 1/3] t7405: add a file/submodule conflict
On Tue, Jul 10, 2018 at 8:53 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> On Tue, Jul 10, 2018 at 8:28 AM Elijah Newren <newren@xxxxxxxxx> 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!