git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH 1/7] merge-ort: extract handling of priv member into reusable function
Date: Thu, 13 Jun 2024 14:00:00 -0700	[thread overview]
Message-ID: <xmqqjzisimnj.fsf@gitster.g> (raw)
In-Reply-To: <d4ba1fccd9145db9b3fe1530881052315cfa16b8.1718310307.git.gitgitgadget@gmail.com> (Elijah Newren via GitGitGadget's message of "Thu, 13 Jun 2024 20:25:01 +0000")

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> +static void move_opt_priv_to_result_priv(struct merge_options *opt,
> +					 struct merge_result *result)
> +{
> +	/*
> +	 * opt->priv and result->priv are a bit weird.  opt->priv contains
> +	 * information that we can re-use in subsequent merge operations to
> +	 * enable our cached renames optimization.  The best way to provide
> +	 * that to subsequent merges is putting it in result->priv.
> +	 * However, putting it directly there would mean retrofitting lots
> +	 * of functions in this file to also take a merge_result pointer,
> +	 * which is ugly and annoying.  So, we just make sure at the end of
> +	 * the merge (the outer merge if there are internal recursive ones)
> +	 * 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;
> +	}
> +}
> +
>  /*
>   * Originally from merge_trees_internal(); heavily adapted, though.
>   */
> @@ -5060,11 +5082,7 @@ 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) {
> -		result->priv = opt->priv;
> -		result->_properly_initialized = RESULT_INITIALIZED;
> -		opt->priv = NULL;
> -	}
> +	move_opt_priv_to_result_priv(opt, result);
>  }

I have a feeling that making it the caller's responsibility to check
"are we doing the outermost merge?"  and not the callee's problem
would result in a better code organization.  If we write

	if (!opt->priv->call_depth)
		move_opt_priv_to_result_priv(opt, result);

then for this call site, it is still crystal clear that this will
happen only at the outermost level.  The new caller you add in the
next step would also be simpler to reason about.

You have the assert() to make sure callers do not call the "move"
helper at a wrong place already, and if the organization in this
patch somehow comes from a desire that the "move" is done only at
the outermost level (and "or immediately before an error causes the
whole thing to abort" after the next patch), it does not have to be
a silent "if call_depth is not zero we return silently", but another
assert() that insists that the callers are allowed to call it under
these two specific conditions.

Thanks.

  reply	other threads:[~2024-06-13 21:00 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13 20:25 [PATCH 0/7] Fix and improve some error codepaths in merge-ort Elijah Newren via GitGitGadget
2024-06-13 20:25 ` [PATCH 1/7] merge-ort: extract handling of priv member into reusable function Elijah Newren via GitGitGadget
2024-06-13 21:00   ` Junio C Hamano [this message]
2024-06-13 22:52     ` Taylor Blau
2024-06-13 20:25 ` [PATCH 2/7] merge-ort: maintain expected invariant for priv member Elijah Newren via GitGitGadget
2024-06-13 22:59   ` Taylor Blau
2024-06-19  2:58     ` Elijah Newren
2024-06-13 20:25 ` [PATCH 3/7] merge-ort: fix type of local 'clean' var in handle_content_merge() Elijah Newren via GitGitGadget
2024-06-13 20:25 ` [PATCH 4/7] merge-ort: clearer propagation of failure-to-function from merge_submodule Elijah Newren via GitGitGadget
2024-06-13 20:25 ` [PATCH 5/7] merge-ort: loosen commented requirements Elijah Newren via GitGitGadget
2024-06-13 20:25 ` [PATCH 6/7] merge-ort: upon merge abort, only show messages causing the abort Elijah Newren via GitGitGadget
2024-06-14  4:19   ` Eric Sunshine
2024-06-19  2:58     ` Elijah Newren
2024-06-13 20:25 ` [PATCH 7/7] merge-ort: convert more error() cases to path_msg() Elijah Newren via GitGitGadget
2024-06-13 23:04 ` [PATCH 0/7] Fix and improve some error codepaths in merge-ort Taylor Blau
2024-06-19  3:00 ` [PATCH v2 " Elijah Newren via GitGitGadget
2024-06-19  3:00   ` [PATCH v2 1/7] merge-ort: extract handling of priv member into reusable function Elijah Newren via GitGitGadget
2024-06-19  3:00   ` [PATCH v2 2/7] merge-ort: maintain expected invariant for priv member Elijah Newren via GitGitGadget
2024-06-28  2:09     ` Derrick Stolee
2024-06-19  3:00   ` [PATCH v2 3/7] merge-ort: fix type of local 'clean' var in handle_content_merge() Elijah Newren via GitGitGadget
2024-06-28  2:44     ` Derrick Stolee
2024-06-19  3:00   ` [PATCH v2 4/7] merge-ort: clearer propagation of failure-to-function from merge_submodule Elijah Newren via GitGitGadget
2024-06-28  2:12     ` Derrick Stolee
2024-06-28  2:38       ` Elijah Newren
2024-06-28  2:47         ` Derrick Stolee
2024-06-19  3:00   ` [PATCH v2 5/7] merge-ort: loosen commented requirements Elijah Newren via GitGitGadget
2024-06-19  3:00   ` [PATCH v2 6/7] merge-ort: upon merge abort, only show messages causing the abort Elijah Newren via GitGitGadget
2024-06-19  3:00   ` [PATCH v2 7/7] merge-ort: convert more error() cases to path_msg() Elijah Newren via GitGitGadget
2024-07-02 21:33     ` Jeff King
2024-07-03 15:48       ` Elijah Newren
2024-07-03 18:35         ` Junio C Hamano
2024-07-06  6:11         ` Jeff King
2024-06-28  2:45   ` [PATCH v2 0/7] Fix and improve some error codepaths in merge-ort Derrick Stolee
2024-06-28 17:11     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqjzisimnj.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=newren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).