Re: [PATCH v3 8/8] merge-recursive: improve rename/rename(1to2)/add[/add] handling
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Oct 31, 2018, 15:08 UTC
- 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:
Show 8 quoted lines
> [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.
Show 5 quoted lines
> + } 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