Elijah Newren <new...@gmail.com> writes:
> There were a few cases in merge-recursive that could result in a check for
> the presence of files in the working copy while trying to create a virtual
> merge base. These were rare and innocuous, but somewhat illogical. The
> two cases were:
>
> * When there was naming conflicts (e.g. a D/F conflict) and we had to
> pick a new unique name for a file. Since the new name is somewhat
> arbitrary, it didn't matter that we consulted the working copy to
> avoid picking a filename it has, but since the virtual merge base is
> never checked out, it's a waste of time and slightly odd to do so.
>
> * When two different files get renamed to the same name (on opposite
> sides of the merge), we needed to delete the original filenames from
> the cache and possibly also the working directory. The caller's check
> for determining whether to delete from the working directory was a
> call to would_lose_untracked(). It turns out this didn't matter
> because remove_file() had logic to avoid modifying the working
> directory when creating a virtual merge base, but there is no reason
> for the caller to check the working directory in such circumstances.
> It's a waste of time, if not also a bit weird.
I think "avoid checking" and "waste of time" are understatements, in
that they make it sound as if the current code is OK and this change
is only to reduce waste. But doesn't the code misbehave if you had
a file in the working tree whose path happens to be the same as the
one involved in these codepaths (iow, if they did not check these
paths in the working tree, the internal merge may succeed, but it
would unnecessarily fail)?
Subject: merge-recursive: do not check working tree during an internal merge
or something, perhaps?
> Signed-off-by: Elijah Newren <new...@gmail.com>
> ---
> merge-recursive.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index d4292de..06d31ed 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -622,7 +622,7 @@ static char *unique_path(struct merge_options *o, const
> char *path, const char *
> base_len = newpath.len;
> while (string_list_has_string(&o->current_file_set, newpath.buf) ||
> string_list_has_string(&o->current_directory_set, newpath.buf) ||
> - file_exists(newpath.buf)) {
> + (!o->call_depth && file_exists(newpath.buf))) {
> strbuf_setlen(&newpath, base_len);
> strbuf_addf(&newpath, "_%d", suffix++);
> }
> @@ -1234,8 +1234,8 @@ static void conflict_rename_rename_2to1(struct
> merge_options *o,
> a->path, c1->path, ci->branch1,
> b->path, c2->path, ci->branch2);
>
> - remove_file(o, 1, a->path, would_lose_untracked(a->path));
> - remove_file(o, 1, b->path, would_lose_untracked(b->path));
> + remove_file(o, 1, a->path, o->call_depth ||
> would_lose_untracked(a->path));
> + remove_file(o, 1, b->path, o->call_depth ||
> would_lose_untracked(b->path));
>
> mfi_c1 = merge_file_special_markers(o, a, c1, &ci->ren1_other,
> o->branch1, c1->path,
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
