Re: [PATCH v4 1/3] replay: refactor enum replay_mode into a bool

From: Patrick Steinhardt <ps@pks.im>
Date: Jun 22, 2026, 13:53 UTC
Message-ID: <ajk-YQxLWfspNWIm@pks.im>
In-Reply-To: <20260622-toon-git-replay-drop-merges-v4-1-ff257f534319@iotcl.com>

On Mon, Jun 22, 2026 at 02:41:55PM +0200, Toon Claes wrote:

Show 17 quoted lines

> In 2760ee4983 (replay: add --revert mode to reverse commit changes,
> 2026-03-26) the enum `replay_mode` was introduced. This has two possible
> values:
> 
>  - The value `REPLAY_MODE_REVERT` is used when option `--revert` is
>    passed to git-replay(1). When using this value the commits are
>    processed in reverse order and the inverse of the changes are
>    applied.
> 
>  - The value `REPLAY_MODE_PICK` is used when either option `--onto` or
>    `--advance` is used. In both cases the commits are processed in
>    normal order, and the changes are applied as-is.
> 
> Since there are only two possible values of this enum, simplify the code
> by converting the enum into a bool. This avoids adding code paths that
> check for invalid values of the enum, and shortens code where the value
> is checked with a ternary operator.

That's fair, and the result is easier to write. But is it really easier to read? And what if we ever have to create a third mode going forward?

I'm generally no fan of booleans as parameters as they basically give you no information at all at the callsite, except if you're lucky and you already have an aptly-named variable available that you can pass. Which seems to be the case here, but I'm still not sure whether this change really improves the code.

Patrick