Re: [PATCH v3 8/8] merge-recursive: improve rename/rename(1to2)/add[/add] handling

[Elijah Newren <newren@gmail.com>]

On Thu, Nov 1, 2018 at 12:01 AM Elijah Newren <newren@gmail.com> wrote:
>
> On Wed, Oct 31, 2018 at 8:08 AM Derrick Stolee <stolee@gmail.com> wrote:
> >
> > On 10/19/2018 3:31 PM, Elijah Newren wrote:
> > > [snip]
> > >
> > > +                     char *new_path = NULL;
> > > +                     if (dir_in_way(b->path, !o->call_depth, 0)) {
> > > +                             new_path = unique_path(o, b->path, ci->branch2);
> > > +                             output(o, 1, _("%s is a directory in %s adding "
> > > +                                            "as %s instead"),
> > > +                                    b->path, ci->branch1, new_path);
> >
> > I tried really hard, but failed to get a test to cover the block below.
> > I was able to
> > find that the "check handling of differently renamed file with D/F
> > conflicts" test
> > in t6022-merge-rename.sh covers the block above. Trying to tweak the
> > example using
> > untracked files seems to hit an error message from unpack-trees.c instead.
> >
> > > +                     } else if (would_lose_untracked(b->path)) {
> > > +                             new_path = unique_path(o, b->path, ci->branch2);
> > > +                             output(o, 1, _("Refusing to lose untracked file"
> > > +                                            " at %s; adding as %s instead"),
> > > +                                    b->path, new_path);
> >

So now I'm confused.  This block was not listed in your coverage
report[1].  And, in fact, I think this block IS covered by testcase
10c of t6043.  However, there is a very similar looking block about 30
lines up that is uncovered (and which was mentioned in your report):

            } else if (would_lose_untracked(a->path)) {
                new_path = unique_path(o, a->path, ci->branch1);
                output(o, 1, _("Refusing to lose untracked file"
                           " at %s; adding as %s instead"),
                       a->path, new_path);

covering it, I think, is just a matter of repeating the 10c test with
the merge repeated in the other direction (checkout B and merge A
instead of checking out A and merging B) -- and touching up the checks
accordingly.

However, now I'm wondering if I'm crazy.  Was it really the block you
had highlighted that you were seeing uncovered?

Thanks,
Elijah

[1] https://public-inbox.org/git/62f0bcf6-aa73-c192-d804-e6d69cac146f@gmail.com/