[prev in list] [next in list] [prev in thread] [next in thread]
List: git
Subject: Re: [PATCH v3 4/8] merge-recursive: new function for better colliding conflict resolutions
From: Derrick Stolee <stolee () gmail ! com>
Date: 2018-10-31 13:57:37
Message-ID: 95a236fd-a757-81ad-34aa-b26b3c3b6e85 () gmail ! com
[Download RAW message or body]
On 10/31/2018 9:53 AM, Derrick Stolee wrote:
> 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.
Nevermind on the PATCH 8/8 situation. I thought I saw you pass (a->path,
NULL) and
(b->path, NULL) into the (prev_path1, prev_path2) pairs, but in each
case the non-NULL
parameter is actually for 'collide_path'.
It is still interesting if we can hit this case. Perhaps we need a
different kind of
conflict, like (rename, delete) [but I struggle to make sense of how to
do that].
Thanks,
-Stolee
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic