From: Derrick Stolee <stolee@gmail.com>
Date: Wed, 31 Oct 2018 13:53:40 GMT
Subject: Re: [PATCH v3 4/8] merge-recursive: new function for better colliding conflict resolutions
Message-ID: <0b84c95b-38bc-e39e-a033-81eb3e7b8202@gmail.com>
In-Reply-To: <20181019193111.12051-5-newren@gmail.com>

On 10/19/2018 3:31 PM, Elijah Newren wrote:
> +#if 0 // #if-0-ing avoids unused function warning; will make live in next commit
> +static int handle_file_collision(struct merge_options *o,
> +				 const char *collide_path,
> +				 const char *prev_path1,
> +				 const char *prev_path2,
> +				 const char *branch1, const char *branch2,
> +				 const struct object_id *a_oid,
> +				 unsigned int a_mode,
> +				 const struct object_id *b_oid,
> +				 unsigned int b_mode)
> +{
> +	struct merge_file_info mfi;
> +	struct diff_filespec null, a, b;
> +	char *alt_path = NULL;
> +	const char *update_path = collide_path;
> +
> +	/*
> +	 * In the recursive case, we just opt to undo renames
> +	 */
> +	if (o->call_depth && (prev_path1 || prev_path2)) {
> +		/* Put first file (a_oid, a_mode) in its original spot */
> +		if (prev_path1) {
> +			if (update_file(o, 1, a_oid, a_mode, prev_path1))
> +				return -1;
> +		} else {
> +			if (update_file(o, 1, a_oid, a_mode, collide_path))

The latest test coverage report [1] shows this if statement is never run, so
it appears that every call to this method in the test suite has either
o->call_depth positive, prev_path1 non-NULL, or both prev_path1 and 
prev_path2
NULL.

Is there a way we can add a test case that calls this method with 
o->call_depth
positive, prev_path1 NULL, and prev_path2 non-NULL?

> +				return -1;
> +		}
> +
> +		/* Put second file (b_oid, b_mode) in its original spot */
> +		if (prev_path2) {
> +			if (update_file(o, 1, b_oid, b_mode, prev_path2))

Since this line is covered, we _do_ call the method with prev_path2 
non-NULL, but
prev_path1 must be non-NULL in all cases.

I may have found a reason why this doesn't happen in one of the callers 
you introduced.
I'm going to comment on PATCH 8/8 to see if that is the case.

Thanks,
-Stolee

[1] 
https://public-inbox.org/git/62f0bcf6-aa73-c192-d804-e6d69cac146f@gmail.com/