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

From: Elijah Newren <newren@gmail.com>
Date: Nov 2, 2018, 17:27 UTC
Message-ID: <CABPp-BFwimcDhwMeFcTJLy-omXiBNzZApkyCnSSRfwXvKi2OUQ@mail.gmail.com>
In-Reply-To: <CABPp-BFZugCFDS_A7FrWdRhp7WO0m8jhsqbSnNCSUWnAVz7mtg@mail.gmail.com>

On Thu, Nov 1, 2018 at 12:01 AM Elijah Newren <newren@gmail.com> wrote:

Show 27 quoted lines

>
> 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/