mbox series

[v2,0/7] Fix and improve some error codepaths in merge-ort

Message ID pull.1748.v2.git.1718766019.gitgitgadget@gmail.com (mailing list archive)
Headers show
Series Fix and improve some error codepaths in merge-ort | expand

Message

Derrick Stolee via GitGitGadget June 19, 2024, 3 a.m. UTC
Changes since v1:

 * Remove the conditional outside of move_opt_priv_to_result_priv() for
   patches 1 & 2
 * Fix the consistency issues in patch 6 (refer to updated enum value in
   comment, use consistent prefix on error messages)
 * Fix typo in patch 2
 * Fix incorrect claim in commit message of patch 2 and provide more detail
   about which merges we are interested in checking for a very specific exit
   code.

This series started as a just a fix for the abort hit in merge-ort when
custom merge drivers error out (see
https://lore.kernel.org/git/75F8BD12-7743-4863-B4C5-049FDEC4645E@gearset.com/).
However, while working on that, I found a few other issues around error
codepaths in merge-ort. So this series:

 * Patches 1-2: fix the reported abort problem
 * Patches 3-4: make code in handle_content_merges() easier to handle when
   we hit errors
 * Patch 5: fix a misleading comment
 * Patches 6-7: make error handling (immediate print vs. letting callers get
   the error information) more consistent

The last two patches change the behavior slightly for error codepaths, and
there's a question about whether we should show only the error messages that
caused an early termination of the merge, or if we should also show any
conflict messages for other paths that were handled before we hit the early
termination. These patches made a decision but feel free to take those last
two patches as more of an RFC.

Elijah Newren (7):
  merge-ort: extract handling of priv member into reusable function
  merge-ort: maintain expected invariant for priv member
  merge-ort: fix type of local 'clean' var in handle_content_merge()
  merge-ort: clearer propagation of failure-to-function from
    merge_submodule
  merge-ort: loosen commented requirements
  merge-ort: upon merge abort, only show messages causing the abort
  merge-ort: convert more error() cases to path_msg()

 merge-ort.c           | 168 +++++++++++++++++++++++++++++++-----------
 t/t6406-merge-attr.sh |  42 ++++++++++-
 2 files changed, 164 insertions(+), 46 deletions(-)


base-commit: 8d94cfb54504f2ec9edc7ca3eb5c29a3dd3675ae
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1748%2Fnewren%2Ffix-error-cases-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1748/newren/fix-error-cases-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1748

Range-diff vs v1:

 1:  d4ba1fccd91 ! 1:  5c50c0b3aad merge-ort: extract handling of priv member into reusable function
     @@ merge-ort.c: static void merge_check_renames_reusable(struct merge_result *resul
      +	 * to move it.
      +	 */
      +	assert(opt->priv && !result->priv);
     -+	if (!opt->priv->call_depth) {
     -+		result->priv = opt->priv;
     -+		result->_properly_initialized = RESULT_INITIALIZED;
     -+		opt->priv = NULL;
     -+	}
     ++	result->priv = opt->priv;
     ++	result->_properly_initialized = RESULT_INITIALIZED;
     ++	opt->priv = NULL;
      +}
      +
       /*
     @@ merge-ort.c: static void merge_ort_nonrecursive_internal(struct merge_options *o
      -		result->_properly_initialized = RESULT_INITIALIZED;
      -		opt->priv = NULL;
      -	}
     -+	move_opt_priv_to_result_priv(opt, result);
     ++	if (!opt->priv->call_depth)
     ++		move_opt_priv_to_result_priv(opt, result);
       }
       
       /*
 2:  17c97301baa ! 2:  d1adec6d105 merge-ort: maintain expected invariant for priv member
     @@ Commit message
          Both merge_switch_to_result() and merge_finalize() expect
             opt->priv == NULL && result->priv != NULL
          which is supposed to be set up by our move_opt_priv_to_result_priv()
     -    function.  However, two codepath dealing with error cases did not
     +    function.  However, two codepaths dealing with error cases did not
          execute this necessary logic, which could result in assertion failures
          (or, if assertions were compiled out, could result in segfaults).  Fix
          the oversight and add a test that would have caught one of these
          problems.
      
          While at it, also tighten an existing test for a non-recursive merge
     -    to verify that it fails correctly, i.e. with the expected exit code
     -    rather than with an assertion failure.
     +    to verify that it fails with appropriate status.  Most merge tests in
     +    the testsuite check either for success or conflicts; those testing for
     +    neither are rare and it is good to ensure they support the invariant
     +    assumed by builtin/merge.c in this comment:
     +        /*
     +         * The backend exits with 1 when conflicts are
     +         * left to be resolved, with 2 when it does not
     +         * handle the given merge at all.
     +         */
     +    So, explicitly check for the exit status of 2 in these cases.
      
          Reported-by: Matt Cree <matt.cree@gearset.com>
          Signed-off-by: Elijah Newren <newren@gmail.com>
      
       ## merge-ort.c ##
     -@@ merge-ort.c: static void move_opt_priv_to_result_priv(struct merge_options *opt,
     - 	 * to move it.
     - 	 */
     - 	assert(opt->priv && !result->priv);
     --	if (!opt->priv->call_depth) {
     -+	if (!opt->priv->call_depth || result->clean < 0) {
     - 		result->priv = opt->priv;
     - 		result->_properly_initialized = RESULT_INITIALIZED;
     - 		opt->priv = NULL;
      @@ merge-ort.c: static void merge_ort_nonrecursive_internal(struct merge_options *opt,
       		    oid_to_hex(&side1->object.oid),
       		    oid_to_hex(&side2->object.oid));
     @@ merge-ort.c: static void merge_ort_nonrecursive_internal(struct merge_options *o
       		return;
       	}
       	trace2_region_leave("merge", "collect_merge_info", opt->repo);
     +@@ merge-ort.c: static void merge_ort_nonrecursive_internal(struct merge_options *opt,
     + 		/* existence of conflicted entries implies unclean */
     + 		result->clean &= strmap_empty(&opt->priv->conflicted);
     + 	}
     +-	if (!opt->priv->call_depth)
     ++	if (!opt->priv->call_depth || result->clean < 0)
     + 		move_opt_priv_to_result_priv(opt, result);
     + }
     + 
      
       ## t/t6406-merge-attr.sh ##
      @@ t/t6406-merge-attr.sh: test_expect_success !WINDOWS 'custom merge driver that is killed with a signal'
 3:  23bb3386114 = 3:  034b91db1d2 merge-ort: fix type of local 'clean' var in handle_content_merge()
 4:  2789c58cd3f = 4:  2813a15b48b merge-ort: clearer propagation of failure-to-function from merge_submodule
 5:  975fbddf305 = 5:  750acae4dba merge-ort: loosen commented requirements
 6:  71391b18c1a ! 6:  6756956d0c7 merge-ort: upon merge abort, only show messages causing the abort
     @@ merge-ort.c: enum conflict_and_info_types {
      +
      +	/*
      +	 * Something is seriously wrong; cannot even perform merge;
     -+	 * Keep this group _last_ other than NB_CONFLICT_TYPES
     ++	 * Keep this group _last_ other than NB_TOTAL_TYPES
      +	 */
      +	ERROR_SUBMODULE_CORRUPT,
       
     @@ merge-ort.c: static int merge_submodule(struct merge_options *opt,
      -		path_msg(opt, CONFLICT_SUBMODULE_CORRUPT, 0,
      +		path_msg(opt, ERROR_SUBMODULE_CORRUPT, 0,
       			 path, NULL, NULL, NULL,
     - 			 _("Failed to merge submodule %s "
     +-			 _("Failed to merge submodule %s "
     ++			 _("error: failed to merge submodule %s "
       			   "(repository corrupt)"),
     + 			 path);
     + 		ret = -1;
      @@ merge-ort.c: static int merge_submodule(struct merge_options *opt,
       	}
       	ret2 = repo_in_merge_bases(&subrepo, commit_b, commit_a);
 7:  32ae44b6260 ! 7:  500433edf49 merge-ort: convert more error() cases to path_msg()
     @@ Commit message
      
       ## merge-ort.c ##
      @@ merge-ort.c: enum conflict_and_info_types {
     - 	 * Keep this group _last_ other than NB_CONFLICT_TYPES
     + 	 * Keep this group _last_ other than NB_TOTAL_TYPES
       	 */
       	ERROR_SUBMODULE_CORRUPT,
      +	ERROR_THREEWAY_CONTENT_MERGE_FAILED,

Comments

Derrick Stolee June 28, 2024, 2:45 a.m. UTC | #1
On 6/18/24 11:00 PM, Elijah Newren via GitGitGadget wrote:
> This series started as a just a fix for the abort hit in merge-ort when
> custom merge drivers error out (see
> https://lore.kernel.org/git/75F8BD12-7743-4863-B4C5-049FDEC4645E@gearset.com/).
> However, while working on that, I found a few other issues around error
> codepaths in merge-ort. So this series:
> 
>   * Patches 1-2: fix the reported abort problem
>   * Patches 3-4: make code in handle_content_merges() easier to handle when
>     we hit errors
>   * Patch 5: fix a misleading comment
>   * Patches 6-7: make error handling (immediate print vs. letting callers get
>     the error information) more consistent

I saw this in Junio's email about series requiring review, so I took a
look despite missing v1. Stepping through each commit in my local copy
helped make sure that these changes were correct in their proper context.

> The last two patches change the behavior slightly for error codepaths, and
> there's a question about whether we should show only the error messages that
> caused an early termination of the merge, or if we should also show any
> conflict messages for other paths that were handled before we hit the early
> termination. These patches made a decision but feel free to take those last
> two patches as more of an RFC.

I also support this change in the final two patches.

One thing I mentioned in an earlier reply was "why not use an
enum in this tri-state 'clean' variable?" and then I tried to
make just such a patch. There were two problems:

  1. There were hundreds of changes that would be difficult to
     do in small bits (but maybe doable).

  2. There is already an 'enum ll_merge_result' in merge-ll.h
     that is silently passed back from merge_3way() in merge-ort.c.
     While it's technically four states, maybe it would suffice to
     use that enum instead of creating a new one.

But I'll leave that as something to think about another time. It
does not change the merit of this series. I left a note about
another "&=" case that wasn't touched, but it's not wrong as-is.

Thanks,
-Stolee
Junio C Hamano June 28, 2024, 5:11 p.m. UTC | #2
Derrick Stolee <stolee@gmail.com> writes:

> I saw this in Junio's email about series requiring review, so I took a
> look despite missing v1. Stepping through each commit in my local copy
> helped make sure that these changes were correct in their proper context.
>
>> The last two patches change the behavior slightly for error codepaths, and
>> there's a question about whether we should show only the error messages that
>> caused an early termination of the merge, or if we should also show any
>> conflict messages for other paths that were handled before we hit the early
>> termination. These patches made a decision but feel free to take those last
>> two patches as more of an RFC.
>
> I also support this change in the final two patches.
>
> One thing I mentioned in an earlier reply was "why not use an
> enum in this tri-state 'clean' variable?" and then I tried to
> make just such a patch. ...
> ... But I'll leave that as something to think about another time. It
> does not change the merit of this series. I left a note about
> another "&=" case that wasn't touched, but it's not wrong as-is.

Thanks for having done a thorough review, including exploration of
an alternative.  Really appreciated.