On Thu, Nov 1, 2018 at 12:01 AM Elijah Newren <new...@gmail.com> wrote:
>
> On Wed, Oct 31, 2018 at 8:08 AM Derrick Stolee <sto...@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-e6d69cac1...@gmail.com/
