From: Derrick Stolee <stolee@gmail.com>
Date: Wed, 31 Oct 2018 15:08:45 GMT
Subject: Re: [PATCH v3 8/8] merge-recursive: improve rename/rename(1to2)/add[/add] handling
Message-ID: <d23b4e26-4df4-273d-a75c-a0af915a6e5e@gmail.com>
In-Reply-To: <20181019193111.12051-9-newren@gmail.com>

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);

It could also be that I failed because I'm less familiar with this part 
of the
codebase. Elijah, do you think it is possible to hit this block?

Thanks,
-Stolee