git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 2/3] merge-ort: add comment to avoid surprise with new sub_flag variable

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 17, 2022, 21:45 UTC
Message-ID
<xmqqedxetuhg.fsf@gitster.g>
In-Reply-To
<340c0f46f74acd641945fceba5ab5feac011ae60.1660718028.git.gitgitgadget@gmail.com>
"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 9 quoted lines
> From: Elijah Newren <newren@gmail.com>
>
> Commit 4057523a40 ("submodule merge: update conflict error message",
> 2022-08-04) added a sub_flag variable that is used to store a value from
> enum conflict_and_info_types, but initializes it with an invalid value
> of -1.  The code may never set it to a valid value, and use the invalid
> one.  This can be surprising when reading over the code at first, but it
> was intentional.  Add a comment making it clear that it is okay to be
> using an invalid value, due to how it is used later.

The current code uses -1 as the "suggest the default course of action", so -1 is very much a "valid value" from the viewpoint of the code that suggests how to resolve. It indeed is an invalid value from the viewpoint of those who maintain conflict_and_info_types enum.

Show 18 quoted lines
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  merge-ort.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/merge-ort.c b/merge-ort.c
> index 67159fc6ef9..0a935a8135f 100644
> --- a/merge-ort.c
> +++ b/merge-ort.c
> @@ -1886,7 +1886,7 @@ cleanup:
>  		const char *abbrev;
>  
>  		util = xmalloc(sizeof(*util));
> -		util->flag = sub_flag;
> +		util->flag = sub_flag; /* May still be -1 */
>  		util->abbrev = NULL;
>  		if (!sub_not_initialized) {
>  			abbrev = repo_find_unique_abbrev(&subrepo, b, DEFAULT_ABBREV);

This new comment may be a slight improvement, but a valid value of sub_flag is used only to signal the situation where the code does not know what to suggest, which feels backwards for longer-term code evolution. Presumably, we would use the util->flag field to store which of the known cases we know what to suggest as we know better.

I wonder if we should initialize the variable to the most generic CONFLICT_SUBMODULE_FAILED_TO_MERGE instead of -1. The value would mean "use the default suggestion", and the two known unworkable values (not-initialized and history-not-available) are currently handled according to what these two values mean. We may later add more specialization based on other CONFLICT_SUBMODULE_* values.

Thanks.
Previous: Elijah Newren via GitGitGadgetNext: Elijah Newren
Message 9 of 16 in “Fixups for cw/submodule-merge-messages”
  1. 0/3 Fixups for cw/submodule-merge-messagesElijah Newren via GitGitGadget, Aug 17, 2022
  2. 1/3 merge-ort: remove translator lego in new "submodule conflict suggestion"Elijah Newren via GitGitGadget, Aug 17, 2022
  3. 2/3 merge-ort: add comment to avoid surprise with new sub_flag variableElijah Newren via GitGitGadget, Aug 17, 2022
  4. 3/3 merge-ort: provide helpful submodule update message when possibleElijah Newren via GitGitGadget, Aug 17, 2022
  5. Junio C HamanoAug 17, 2022
  6. 0/3 Fixups for cw/submodule-merge-messagesElijah Newren via GitGitGadget, Aug 17, 2022
  7. 1/3 merge-ort: remove translator lego in new "submodule conflict suggestion"Elijah Newren via GitGitGadget, Aug 17, 2022
  8. 2/3 merge-ort: add comment to avoid surprise with new sub_flag variableElijah Newren via GitGitGadget, Aug 17, 2022
  9. Junio C HamanoAug 17, 2022
  10. Elijah NewrenAug 18, 2022
  11. 3/3 merge-ort: provide helpful submodule update message when possibleElijah Newren via GitGitGadget, Aug 17, 2022
  12. Junio C HamanoAug 17, 2022
  13. 0/3 Fixups for cw/submodule-merge-messagesElijah Newren via GitGitGadget, Aug 18, 2022
  14. 1/3 merge-ort: remove translator lego in new "submodule conflict suggestion"Elijah Newren via GitGitGadget, Aug 18, 2022
  15. 2/3 merge-ort: avoid surprise with new sub_flag variableElijah Newren via GitGitGadget, Aug 18, 2022
  16. 3/3 merge-ort: provide helpful submodule update message when possibleElijah Newren via GitGitGadget, Aug 18, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.