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

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> On Tue, Oct 27, 2026 at 12:40:45PM -0700, Junio C Hamano wrote:
>> "Mark C. Chu-Carroll" <markchucarroll@fastmail.com> writes:
>> 
>> > On Tue, 27 Oct 2026 11:46:45 +0100, Patrick Steinhardt <ps@pks.im> wrote:
>> >> Our modern coding guidelines say that flags should typically be passed
>> >> around as enums so that it becomes trivial to see what kind of flags are
>> >> expected. Adapt the rerere flags accordingly.
>> >> 
>> >>   <snip>
>> >> +enum rerere_flags {
>> >> +	RERERE_AUTOUPDATE = (1 << 0),
>> >> +	RERERE_NOAUTOUPDATE = (1 << 1),
>> >> +	RERERE_READONLY = (1 << 2),
>> >> +	/* If MERGE_RR.lock is taken, return -1 as if rerere were disabled */
>> >> +	RERERE_NOWAIT = (1 << 3),
>> >> +};
>> >
>> > If we're moving to using enum flags, then wouldn't it be better to
>> > explicitly add a "RERE_MERGE_LOCK_TOKEN" to the enum for that case, 
>> > rather than have this value only documented by a comment?
>> 
>> Perhaps you misunderstand what the comment says.  It is an
>> explanation for the next line, i.e., it tells the API users "If you
>> want the 'immediate failure when locked' behaviour, pass the _NOWAIT
>> bit".
>
> Yeah, this. I guess we can help that though by documenting all of the
> flags while at it.

Great.