Re: [PATCH v3 10/10] xdiff: treat xdfile_t.rchg like an enum

From: Ezekiel Newren <ezekielnewren@gmail.com>
Date: Sep 21, 2025, 00:38 UTC
Message-ID: <CAH=ZcbD4oi1hdWDK8s2g6mQGrk+kwWffnSYE5gQZ_d3Z2Z3euA@mail.gmail.com>
In-Reply-To: <xmqqms6owu7o.fsf@gitster.g>

On Sat, Sep 20, 2025 at 6:00 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> I am not comfortable with the idea of exposing a set of overly
> genericly named macros like these, especially when they are *meant*
> only to be used with xdfile_t.rchg, to those *.c files.  So far,
> when they include <xdiff-interface.h> (or <ll-merge.h>), they have
> been rest assured that their namespaces won't be contaminated and
> they would not risk stepping on others' toes as long as they stay
> away from inventing their own xdsomething or s_xsomething (neither
> of which is quite similar to how we name our symbols and types).

What if I move NO, YES, MAYBE into xprepare.c and refactor `char rchg` to `bool changed`? The problem with bool is that C needs to include stdbool.h to match how Rust defines bool. git-compat-util.h didn't include it, then it did, then it didn't because compat/posix.h included it instead.

How do you feel about xdiff.h including compat/posix.h too? If we don't use bool on the C side then Rust is going to be littered with some_condition != 0 or other_condition == 0 and won't be as clear that it's a boolean instead of a numeric type.