Re: [PATCH v3 02/12] rerere: convert flags into an enum

[Patrick Steinhardt <ps@pks.im>]

On Mon, Nov 09, 2026 at 11:13:53AM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Patrick Steinhardt <ps@pks.im> writes:
> >
> >>> What BOTH versions lack is an explanation why RERERE_NOAUTOUPDATE is
> >>> needed in the first place.  In other words, "How is it different
> >>> from the lack of RERERE_AUTOUPDATE bit?" is not answered here.  And
> >>> I think that is a lot more important thing to clarify.
> >>
> >> Heh, in this case _I_ thought that it's implicitly clear from the
> >> comment of `RERERE_AUTOUPDATE`: it overrides "rerere.autoUpdate". I
> >> figured that updating these comments would cause some discussions, and
> >> that's exactly why I didn't dare to update them at all in v1 :)
> >
> > ;-)
> 
> The command line can give us not two (which could be represented
> with a single bit) but three choices, (0) the command line has no
> preference on --[no-]autoupdate and follow the configured default,
> (1) --autoupdate, or (2) --no-autoupdate, and that is exactly why we
> have these two independent-looking bits.
> 
> But two bits can express another combination (i.e., both bits on),
> which probably is invalid.  The underlying OPT_UYN() calls
> parse_opt_tertiary() which only chooses between 1 and 2 so we should
> be safe on the setting side, but I offhand do not remember if we
> detect when both bits are on and BUG() out where we consume the
> value.

We have this bit in `rerere_cache_setup()`:

	if (flags & (RERERE_AUTOUPDATE|RERERE_NOAUTOUPDATE))
		cache->autoupdate = !!(flags & RERERE_AUTOUPDATE);

So `RERERE_AUTOUPDATE` takes precedence over `RERERE_NOAUTOUPDATE`, but
all callers know to only pass one of these flags. I agree though that we
should detect this misuse and complain about it, it's certainly not
obvious at all.

Patrick