From: Derrick Stolee <stolee@gmail.com>
To: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Cc: Taylor Blau <me@ttaylorr.com>,
Eric Sunshine <sunshine@sunshineco.com>,
Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH v2 4/7] merge-ort: clearer propagation of failure-to-function from merge_submodule
Date: Thu, 27 Jun 2024 22:12:08 -0400 [thread overview]
Message-ID: <63caecb4-19cd-4b6f-91f0-bd00df2ecb54@gmail.com> (raw)
In-Reply-To: <2813a15b48b70ead7e3fd062d1b49baee665fc9d.1718766019.git.gitgitgadget@gmail.com>
On 6/18/24 11:00 PM, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
>
> The 'clean' member variable is somewhat of a tri-state (1 = clean, 0 =
> conflicted, -1 = failure-to-determine), but we often like to think of
> it as binary (ignoring the possibility of a negative value) and use
> constructs like '!clean' to reflect this. However, these constructs
> can make codepaths more difficult to understand, unless we handle the
> negative case early and return pre-emptively; do that in
> handle_content_merge() to make the code a bit easier to read.
This patch is correct and valuable.
Would it be valuable to go a bit further and turn 'clean' into
an enum that reflects these states? Perhaps that would prevent
future changes from slipping into this mistake.
Thanks,
-Stolee
next prev parent reply other threads:[~2024-06-28 2:12 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
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 [this message]
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=63caecb4-19cd-4b6f-91f0-bd00df2ecb54@gmail.com \
--to=stolee@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=me@ttaylorr.com \
--cc=newren@gmail.com \
--cc=sunshine@sunshineco.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.