[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH v3 8/8] merge-recursive: improve rename/rename(1to2)/add[/add] handling
From:       Derrick Stolee <stolee () gmail ! com>
Date:       2018-10-31 15:08:45
Message-ID: d23b4e26-4df4-273d-a75c-a0af915a6e5e () gmail ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]