Subject: bug#78813: feature/igc: [PATCH] Make the array face_attr_sym readonly

From: Eli Zaretskii <[email-masked]>
Date: Sun, 22 Jun 2025 10:17:39 +0300

> Date: Sun, 22 Jun 2025 06:34:11 +0000
> From: Pip Cet <[email-masked]>
> Cc: [email-masked], [email-masked]
> 
> "Eli Zaretskii" <[email-masked]> writes:
> 
> >> Date: Sat, 21 Jun 2025 10:07:43 +0000
> >> From: Pip Cet <[email-masked]>
> >> Cc: [email-masked], [email-masked]
> >>
> >> "Eli Zaretskii" <[email-masked]> writes:
> >>
> >> >> Sorry I'm asking for clarification, but my impression was the igc branch
> >> >> was to change very little in the !HAVE_MPS case, because general GC
> >> >> cleanups such as this one make more sense on the main branch: fewer
> >> >> merge conflicts, we'll see the benefits before merging the branch (or
> >> >> even if for some reason we never do), a better git history, better test
> >> >> coverage for pre-push testing.
> >> >
> >> > That's true in general, but if some change in the non-MPS case makes
> >> > the overall code cleaner, there should be no reason not to make it on
> >> > the branch.
> 
> This is what you said: a "change in the non-MPS case" (so presumably one
> not touching the MPS code) should be made "on the branch".

No, you presume wrong.  I just mean changes in parts of code that are
not compiled in the MPS build.  But see below.

> >> I can't parse that statement.  If a change affects only the non-MPS
> >> case, which branch should we make it on?  The master branch would make
> >> sense to me, and the feature/igc branch doesn't make sense.
> >
> > That's not the situation I alluded to.  Your question was about more
> > general situations: you never said that you are talking about changes
> > that affect _only_ the non-MPS parts of the code.  I replied with the
> > situation in mind where some change affects _both_ MPS and non-MPS
> > parts.
> 
> How is it a "change in the non-MPS case" if it affects both?

A change could affect both MPS and non-MPS code, couldn't it?  Why is
it so hard to understand?

> >> This single change isn't critical, of course, but feature/igc already
> >> contains too many changes which should be merged to master before we
> >> ever consider merging the branch as a whole.  If the strategy is to
> >> increase that number further, that makes a sensible merge of feature/igc
> >> much less likely.
> >
> > Like I said: merge conflicts are a non-issue with modern dVCSes.
> 
> That's not my experience.

We will have to agree to disagree, then.